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 <ebernard(a)redhat.com&gt; 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.

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 <emmanuel(a)hibernate.org&gt;: > 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 >> <ebernard(a)redhat.com&gt; 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev >

On 26 nov. 09, at 09:32, Sanne Grinovero 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? > Ah right, makes sense > 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) > ok > 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 <emmanuel(a)hibernate.org&gt;: > >> 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 >>> <ebernard(a)redhat.com&gt; 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >>

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 <ebernard(a)redhat.com&gt;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. >