[hibernate-dev] [HV] Programmatic definition of method level constraints
Hi guys, I'm working on HV-431, http://opensource.atlassian.com/projects/hibernate/browse/HV-431. The aim of this issue is to extend the programmatic API to allow constraints definition on methods in a programmatic way. I've discussed with Hardy about some proposals and I've made a gist to expose the different possibility, look at https://gist.github.com/903302. Comments and new proposals are welcome :) --Kevin ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [HV] Programmatic definition of method level constraints
https://gist.github.com/903302#file_1_method_configuration.java seems the one that makes most sense by far to me. The other options tend to make method a super concept that is not symmetric with .property() What does //this version doesn't break the compatibility means on other versions? Emmanuel On 8 avr. 2011, at 10:31, Kevin Pollet wrote: > Hi guys, > > I'm working on HV-431, > http://opensource.atlassian.com/projects/hibernate/browse/HV-431. > > The aim of this issue is to extend the programmatic API to allow constraints > definition on methods in a programmatic way. I've discussed with Hardy about > some proposals and I've made a gist to expose the different possibility, look > at https://gist.github.com/903302. > > Comments and new proposals are welcome :) > > --Kevin ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [HV] Programmatic definition of method level constraints
On Fri, 08 Apr 2011 10:47:37 +0200, Emmanuel Bernard wrote: > 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 to reorder/adjust their mapping when upgrading. One reason for that is that atm you can for example specify 'defaultGroupSequence' multiple times. After the changes 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 make 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. --Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [HV] Programmatic definition of method level constraints
On 8 avr. 2011, at 11:09, Hardy Ferentschik wrote: > On Fri, 08 Apr 2011 10:47:37 +0200, Emmanuel Bernard > wrote: > >> 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 to > reorder/adjust their mapping when upgrading. One reason for that is that atm > you can for example specify 'defaultGroupSequence' multiple times. After the > changes > 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 make > 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. > > --Hardy OK I see. I guess that's a fair trade-off and that's super easy to fix on people's code. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [HV] Programmatic definition of method level constraints
Hi, 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, Class... parameterTypes). 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. Gunnar 2011/4/8 Emmanuel Bernard : > > On 8 avr. 2011, at 11:09, Hardy Ferentschik wrote: > >> On Fri, 08 Apr 2011 10:47:37 +0200, Emmanuel Bernard >> wrote: >> >>> 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 to >> reorder/adjust their mapping when upgrading. One reason for that is that atm >> you can for example specify 'defaultGroupSequence' multiple times. After the >> changes >> 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 make >> 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. >> >> --Hardy > > OK I see. > I guess that's a fair trade-off and that's super easy to fix on people's code. > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [HV] Programmatic definition of method level constraints
On vendredi 8 avril 2011 at 13:13, Gunnar Morling wrote: Hi, > > 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, > Class... parameterTypes). > > 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. > > Gunnar Good catch, I haven't seen this case. My thinking is that only ConstraintDef#method(String name, Class... parameterTypes) would suffice (parameterTypes is a varargs and can be empty). --Kevin > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [HV] Programmatic definition of method level constraints
Make sure you write a client of this API, I suspect Class... parameterTypes might not be what you want. On 8 avr. 2011, at 13:41, Kevin Pollet wrote: > On vendredi 8 avril 2011 at 13:13, Gunnar Morling wrote: > >> Hi, >> >> 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, >> Class... parameterTypes). >> >> 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. >> >> Gunnar > > Good catch, I haven't seen this case. > My thinking is that only ConstraintDef#method(String name, Class... > parameterTypes) would suffice (parameterTypes is a varargs and can be empty). > > --Kevin > > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [HV] Programmatic definition of method level constraints
On vendredi 8 avril 2011 at 15:54, Emmanuel Bernard wrote: Make sure you write a client of this API, I suspect Class... parameterTypes might not be what you want. > > On 8 avr. 2011, at 13:41, Kevin Pollet wrote: What do you mean ? Have you a tricky/special case in mind ? --Kevin ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [HV] Programmatic definition of method level constraints
On 8 avr. 2011, at 17:16, Kevin Pollet wrote: > On vendredi 8 avril 2011 at 15:54, Emmanuel Bernard wrote: >> Make sure you write a client of this API, I suspect Class... >> parameterTypes might not be what you want. >> >> On 8 avr. 2011, at 13:41, Kevin Pollet wrote: > > What do you mean ? > Have you a tricky/special case in mind ? > > --Kevin I had method.getParameterTypes() vs method.getGenericParameterTypes in mind. Not sure that plays a role but one might need to explore it. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
