Re: [hibernate-dev] On possible extensions for the validator
On 16 oct. 2010, at 10:56, Dag Hovland wrote:
> On 15/10/10 13:33, Emmanuel Bernard wrote:
> (...)
>> That being said, I wonder whether you can write your approach atop a generic
>> class-level constraint @CrossValidation that would look for the properties
>> annotations and behave as expected. That would be a nice way to offer both
>> world to the users. You will need to "group" cross field constraints though:
>> as I see it on the paper, you can only have one group of cross level
>> constraint for a given constraint type per class.
>
> I do not really understand this. Can you give an example?
class BrokenModel {
@AtLeastOneNotNullAmongst(Group1.class)
A getA() { ... };
@AtLeastOneNotNullAmongst(Group1.class)
@AtLeastOneNotNullAmongst(Group2.class)
B getB() { ... };
@AtLeastOneNotNullAmongst(Group2.class)
C getC() { ... };
}
A or B must be not null and B or C must be not null.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] On possible extensions for the validator
I was also thinking about a generic class level @CrossValidation
constraint. I think Emmanuel and I
are thinking about the same thing here:
@CrossValidations({
@CrossValidation(forGroup=BankAccount.class),
@CrossValidation(forGroup=ContactDetails.class)
})
public class BankAccountNumber {
@ExactlyOneNull(groups=BankAccount.class)
public String getIBAN() {
return IBAN;
}
@ExactlyOneNull(groups=BankAccount.class)
public String getAccount() {
return account;
}
@ExactlyOneNull(groups=ContactDetails.class)
public String getHomeNumber() {
return homeNumber;
}
@ExactlyOneNull(groups=ContactDetails.class)
public String getWorkNumber() {
return workNumber;
}
}
Using groups (or maybe payloads!?) you can have multiple cross validations
of the same type within one entity.
--Hardy
On Mon, 18 Oct 2010 09:48:16 +0200, Emmanuel Bernard
wrote:
>
> On 16 oct. 2010, at 10:56, Dag Hovland wrote:
>
>> On 15/10/10 13:33, Emmanuel Bernard wrote:
>> (...)
>>> That being said, I wonder whether you can write your approach atop a
>>> generic class-level constraint @CrossValidation that would look for
>>> the properties annotations and behave as expected. That would be a
>>> nice way to offer both world to the users. You will need to "group"
>>> cross field constraints though: as I see it on the paper, you can only
>>> have one group of cross level constraint for a given constraint type
>>> per class.
>>
>> I do not really understand this. Can you give an example?
>
> class BrokenModel {
>@AtLeastOneNotNullAmongst(Group1.class)
>A getA() { ... };
>@AtLeastOneNotNullAmongst(Group1.class)
> @AtLeastOneNotNullAmongst(Group2.class)
>B getB() { ... };
>@AtLeastOneNotNullAmongst(Group2.class)
>C getC() { ... };
> }
>
> A or B must be not null and B or C must be not null.
> ___
> 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] and HBMBinder
It's used to allow injecting global meta tags when generating code via hibernate tools. Depending on how hibernate 4 refactoring goes we might not need it anymore...i.e. since hibernate tools would need a rewrite anyway ;0) /max On Oct 16, 2010, at 21:25, Steve Ebersole wrote: > HBMBinder.bindRoot excepts a java.util.Map parameters called > 'inheritedMetas'. > Thing is, that parameter is really useless. That method is called from a > single place in the Hibernate Core code and that value is defined as > CollectionHelper.EMPTY_MAP in said caller. > > So either this code changed in such a way that this parameter was no longer > needed but never removed, or another project uses it differently. Do we need > this passed in still? > > --- > Steve Ebersole > http://hibernate.org > ___ > 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] On possible extensions for the validator
Ok now I see it.
Using groups for cross-validation is a very nice solution to be able to
reuse them on multiple sets of properties.
Then in Emmanuel's example I guess it should be
@AtLeastOneNotNullAmongst(groups={Group1.class,Group2.class})
B getB() { ... };
The @CrossValidation annotation at class level is definitely a good idea
in order to avoid having a @CrossValidation marker inside
each cross-annotation, and it helps also the user/programmer to
distinguish between normal and cross annotations in the code.
I am a bit concerned about how groups for cross-annotations and normal
annotations would interact with each other.
Should it be possible to mix groups for normal and cross annotations
when defining a @GroupSequence?
Can both an annotation and a cross annotation belong to the same group?
If not, how to enforce that
(by the given example, the validator cannot distinguish between
cross-annotations and normal annotations, and therefore cannot perform
any check.
Of course I am assuming that you don't want to use a @CrossAnnotation
marker in the annotation declaration, or all of this would not be a
problem at all) ?
I can think of two ways right now:
1) We might have the cross-annotations themselves defined at class-level
rather than the groups. Like:
@Crossvalidations(CrossAnnotations={ExactlyOneNull.class,...})
In this way the validator (and the user) would know straight away which
are cross annotations and which not, and groups could still be used in
the same way at method level.
2.a) If a class defining a groups implemented some @interface Group"
then one could create something like "CrossGroup extends Group" and have
special groups reserved for cross-annotation:
@Crossvalidations(CrossGroups{BankAccount.class,ContactDetails.class})
The CrossGroup element in the annotation declaration would then work as
an implicit marker, so that annotations using those groups must be
cross-annotations and normal annotations would not be able to use them.
2.b) There exists a default group for all cross-annotations
en 18.10.2010 11:11, skrev Hardy Ferentschik:
> I was also thinking about a generic class level @CrossValidation
> constraint. I think Emmanuel and I
> are thinking about the same thing here:
>
> @CrossValidations({
> @CrossValidation(forGroup=BankAccount.class),
> @CrossValidation(forGroup=ContactDetails.class)
> })
> public class BankAccountNumber {
>
> @ExactlyOneNull(groups=BankAccount.class)
> public String getIBAN() {
> return IBAN;
> }
>
> @ExactlyOneNull(groups=BankAccount.class)
> public String getAccount() {
> return account;
> }
>
>
> @ExactlyOneNull(groups=ContactDetails.class)
> public String getHomeNumber() {
> return homeNumber;
> }
>
> @ExactlyOneNull(groups=ContactDetails.class)
> public String getWorkNumber() {
> return workNumber;
> }
> }
>
> Using groups (or maybe payloads!?) you can have multiple cross validations
> of the same type within one entity.
>
> --Hardy
>
>
> On Mon, 18 Oct 2010 09:48:16 +0200, Emmanuel Bernard
> wrote:
>
>> On 16 oct. 2010, at 10:56, Dag Hovland wrote:
>>
>>> On 15/10/10 13:33, Emmanuel Bernard wrote:
>>> (...)
That being said, I wonder whether you can write your approach atop a
generic class-level constraint @CrossValidation that would look for
the properties annotations and behave as expected. That would be a
nice way to offer both world to the users. You will need to "group"
cross field constraints though: as I see it on the paper, you can only
have one group of cross level constraint for a given constraint type
per class.
>>> I do not really understand this. Can you give an example?
>> class BrokenModel {
>> @AtLeastOneNotNullAmongst(Group1.class)
>> A getA() { ... };
>> @AtLeastOneNotNullAmongst(Group1.class)
>> @AtLeastOneNotNullAmongst(Group2.class)
>> B getB() { ... };
>> @AtLeastOneNotNullAmongst(Group2.class)
>> C getC() { ... };
>> }
>>
>> A or B must be not null and B or C must be not null.
>> ___
>> 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
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] and HBMBinder
We should talk about what is required here to make sure it supports the use case(s) you need. "global" I assume means applying to all tags. That is doable. Currently, using the prelimiary code, that would look like: Map globalMeta = ...; Metadata metadata = ...; // Metadata is sorta, kida like old Mappings HibernateXmlBinder hbmBinder = new HibernateXmlBinder( meatdata, globalMeta ); hbmBinder.bind( xmlDocument ); hbmBinder.bind( anotherXmlDocument ); ... Not all that much different... On Monday, October 18, 2010, at 06:43 am, Max Rydahl Andersen wrote: > It's used to allow injecting global meta tags when generating code via > hibernate tools. > > Depending on how hibernate 4 refactoring goes we might not need it > anymore...i.e. since hibernate tools would need a rewrite anyway ;0) > > /max > > On Oct 16, 2010, at 21:25, Steve Ebersole wrote: > > HBMBinder.bindRoot excepts a java.util.Map parameters called > > 'inheritedMetas'. Thing is, that parameter is really useless. That > > method is called from a single place in the Hibernate Core code and that > > value is defined as CollectionHelper.EMPTY_MAP in said caller. > > > > So either this code changed in such a way that this parameter was no > > longer needed but never removed, or another project uses it differently. > > Do we need this passed in still? > > > > --- > > Steve Ebersole > > http://hibernate.org > > ___ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev --- Steve Ebersole http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
