Re: [hibernate-dev] Programmatic Mapping patch
Hi
Ive updated the ProvidedId mapping test to include the changes you made.
Also added some more factory methods in the ContainedInMapping. On a side
note, I've made SearchMapping an interface but wasn't sure how to create it,
is there a class I can use to construct a new search mapping? The
SearchConfigurationFromHibernateCore
has a getProgrammaticMapping method which returns a mapping that was set on
the configuration property. Anyway I can hold off on that and create the
patch to address 4 and 5.
Cheers
Amin
On Thu, Nov 26, 2009 at 6:33 AM, Emmanuel Bernard <emmanuel(a)hibernate.org>wrote:
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(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.
>