[hibernate-dev] Programmatic Mapping patch

[Sanne Grinovero]

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?

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)

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 at hibernate.org>:
> 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.
>>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>