[hibernate-dev] Programmatic Mapping patch
emmanuel at hibernate.org
Thu Nov 26 03:41:46 EST 2009
On 26 nov. 09, at 09:32, Sanne Grinovero wrote:
> 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?
Ah right, makes sense
> 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.
> 2009/11/26 Emmanuel Bernard <emmanuel at hibernate.org>:
>> 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.
>>> 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
>>> 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?
>>> 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
>>> - 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
>>> property(String name, ElementType type) should it be replaced with
>>> specific methods like?
>>> .field() => conflict with lucene field
>>> Is date bridge exclusive to calendar bridge? I think the contract
>>> expresses that today.
>>> ContainedInMapping does not contain the necessary upper methods.
>>> 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
More information about the hibernate-dev