Re: [hibernate-dev] Programmatic Mapping patch

Hi So I'll make the following changes 1) Move fulltextfilterdef to a global settings, similar to the Analyzer definitions. This means that SearchFactoryImpl would need to be updated to check for not only entities for filter defs but also in the global settings?

2) Remove analyzerDescriminator from indexEmbedded()

3) Create a SearchMappingFactory class which returns a SearchMapping implementation?

4) Make SearchMapping into an interface

I can have these done and with you by the end of today or tomorrow mornign (I've got a job interview today...gulp) Cheers Amin On Thu, Nov 26, 2009 at 8:41 AM, Emmanuel Bernard <emmanuel(a)hibernate.org > wrote: 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