Hi
In relation to fullTextFilterDef, that was my initial thoughts but I noticed
that the full text filter definition (annotation) was built from an entity
in searchFactoryImpl
private void bindFilterDefs(XClass mappedXClass) {
FullTextFilterDef defAnn = mappedXClass.getAnnotation( FullTextFilterDef.
class );
if ( defAnn != null ) {
bindFilterDef( defAnn, mappedXClass );
}
FullTextFilterDefs defsAnn = mappedXClass.getAnnotation( FullTextFilterDefs.
class );
if ( defsAnn != null ) {
for ( FullTextFilterDef def : defsAnn.value() ) {
bindFilterDef( def, mappedXClass );
}
}
}
Therefore I added it to the entity.
2B) I can update this.
4) There is a CalendarBridge in Hibernate Search (I committed a patch, there
is a JIRA for this, can't remember). Therefore I created a calendarBridge
and dateBridge.
Cheers
Amin
On Thu, Nov 26, 2009 at 7:32 AM, Sanne Grinovero
<sanne.grinov...@gmail.com>wrote:
> About 2)
> 2A - fullTextFilterDef:
> While it's ok for the annotation to stay on an indexed entity, I don't
> see a named filter as coupled/related to an entity, shouldn't this be
> part of global settings?
>
> 2B - analyzerDiscriminator
> yes makes sense only on an indexed entity, not on indexedembeeded as
> it's being ignored on the embedded entity (currently.. improve? not to
> support in API now anyway)
>
> 2C - similarity
> We actually check for only one Similarity being set for a whole index
> (i.e. class hierarchy), so this is not settable on indexedembedded for
> sure. Actually it might make more sense on a index configuration,
> rather than on an entity configuration - if you accept a mismatch in
> how configuration works programmatic vs annotations.
> There's an open issue already to set similarity at index level (in
> addition to annotating the root type), we could consider programmatic
> already improved in this sense.
>
> 4 - > Is date bridge exclusive to calendar bridge? I think the
> contract expresses that today.
> Don't know what you mean, but something is wrong here: we have a
> CalendarBridge and a DateBridge.
>
> Cheers,
> Sanne
>
> 2009/11/26 Emmanuel Bernard <emman...@hibernate.org>:
> > Hey,
> > Let's release Beta1 as it is except for 5 and 6 and take time to try
> > the API before refining it.
> >
> > On 25 nov. 09, at 17:29, Amin Mohammed-Coleman wrote:
> >
> >> Hi All,
> >>
> >> Would it be possible get feedback with regards to points 2, 3 and
> >> 4. I can create patch to address those issues.
> >>
> >> Cheers
> >> Amin
> >>
> >> On Fri, Nov 20, 2009 at 2:20 PM, Emmanuel Bernard
> >> <ebern...@redhat.com> wrote:
> >> Hi Amin,
> >> I've committed your patch, thanks!
> >> There is still some work and questions remaining but that's a big
> >> coverage improvement. Now on to the doc to get the release out :)
> >>
> >> Here is my raw feedback
> >>
> >> 1.
> >> Interface vs class?
> >> Should we start using interfaces instead of classes, at least for
> >> SearchMapping. That way we could hide the getEntityDescriptor()
> >> method to the users.
> >> I think we need to start using superclasses or super interfaces to
> >> enforce the repeated contracts down to the tree of navigation?
> >>
> >> 2.
> >> Should the methods be on IndexedMapping not EntityMapping?
> >> - fullTextFilterDef
> >> - analyzerDiscriminator
> >> - similarity
> >> Question to Hardy and Sanne, do these concepts make sense on a non
> >> @indexed element? I can't remember how the parser behaves.
> >>
> >> I think these methods should be onn IndexedMapping rather than
> >> EntityMapping
> >> - boost
> >> - providedId
> >>
> >> The problem with this approach is that we would need to
> >> differentiate PropertyMapping and IndexedPropertyMapping. I am not
> >> sure this additional complexity is worth the extra help to the
> >> developer.
> >>
> >> 3.
> >> property(String name, ElementType type) should it be replaced with
> >> specific methods like?
> >> .field() => conflict with lucene field
> >> .getter()
> >>
> >> 4.
> >> Is date bridge exclusive to calendar bridge? I think the contract
> >> expresses that today.
> >>
> >> 5.
> >> ContainedInMapping does not contain the necessary upper methods.
> >>
> >> 6.
> >> I've updated the original ProvidedIdTest, Can you push the same
> >> changes to the programmatic version of the test.
> >>
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
