Re: [hibernate-dev] Programmatic Mapping patch

Hi Ive updated the ProvidedId mapping test to include the changes you made. Also added some more factory methods in the ContainedInMapping. On a side note, I've made SearchMapping an interface but wasn't sure how to create it, is there a class I can use to construct a new search mapping? The SearchConfigurationFromHibernateCore has a getProgrammaticMapping method which returns a mapping that was set on the configuration property. Anyway I can hold off on that and create the patch to address 4 and 5. Cheers Amin On Thu, Nov 26, 2009 at 6:33 AM, Emmanuel Bernard <emmanuel(a)hibernate.org > wrote: 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 > > 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. >