Re: [hibernate-dev] Programmatic Mapping patch

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.