On 20 nov. 09, at 15:20, Emmanuel Bernard 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.