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(a)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.