[hibernate-dev] Programmatic Mapping patch

[Emmanuel Bernard]

Yes we need a factory somewhere but I don't know where yet.

On 26 nov. 09, at 09:56, Amin Mohammed-Coleman wrote:

> 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 at 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 at 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.
>>
>
>