[hibernate-dev] Programmatic Mapping patch

[Amin Mohammed-Coleman]

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