I also like https://gist.github.com/903302#file_1_method_configuration.java
best. As we already decided to accept some breaking changes around
ConstraintDef, I also think it's better to do other breaking changes
now instead of later.
Just one remark: we need a way to clearly identify overloaded methods.
In addition to ConstraintDef#method(String name) from the proposal
there should be another method like ConstraintDef#method(String name,
The first could be used if only one method with a given name exists,
the latter if several overloaded methods with the same name exist.
2011/4/8 Emmanuel Bernard <emmanuel(a)hibernate.org>:
On 8 avr. 2011, at 11:09, Hardy Ferentschik wrote:
> On Fri, 08 Apr 2011 10:47:37 +0200, Emmanuel Bernard <emmanuel(a)hibernate.org>
>> What does
>> //this version doesn't break the compatibility
>> means on other versions?
> I also prefer https://gist.github.com/903302#file_1_method_configuration.java
> This version means though that people already using the programmatic API might have
> reorder/adjust their mapping when upgrading. One reason for that is that atm
> you can for example specify 'defaultGroupSequence' multiple times. After the
> you can only specify it after 'type' (which makes sense).
> We already made some changes during the 4.2 development to the programmatic API. If
> we all agree that file_1_method_configuration is the best approach, we should just
> a final adjustment instead of delaying it and changing it post 4.2
> The versions marked w/ "this version doesn't break the compatibility"
won't break any existing
> programmatic mappings, but all of them seem worse than file_1_method_configuration.
OK I see.
I guess that's a fair trade-off and that's super easy to fix on people's
hibernate-dev mailing list