On 26 nov. 09, at 10:59, Amin Mohammed-Coleman wrote:
So I'll make the following changes
1) Move fulltextfilterdef to a global settings, similar to the
Analyzer definitions. This means that SearchFactoryImpl would need
to be updated to check for not only entities for filter defs but
also in the global settings?
2) Remove analyzerDescriminator from indexEmbedded()
3) Create a SearchMappingFactory class which returns a SearchMapping
no not yet, we are not mature.
4) Make SearchMapping into an interface
I can have these done and with you by the end of today or tomorrow
mornign (I've got a job interview today...gulp)
On Thu, Nov 26, 2009 at 8:41 AM, Emmanuel Bernard <emmanuel(a)hibernate.org
On 26 nov. 09, at 09:32, Sanne Grinovero wrote:
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(a)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:
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
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?
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
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