[bv-dev] BVAL-221 Constraint violation builder cannot put constraint on a top level map key
Emmanuel Bernard
emmanuel at hibernate.org
Fri Dec 7 03:56:48 EST 2012
Yes it would. That was my question earlier in this thread. Do we consider the intersection trick acceptable in the specification.
On 7 déc. 2012, at 00:41, Gunnar Morling <gunnar at hibernate.org> wrote:
> Regarding BVAL-221, wouldn't that be fixed by the intersection type approach I suggested? Or do you think it we shouldn't pursue it because its too magic or uncommon?
>
>
> 2012/12/5 Emmanuel Bernard <emmanuel at hibernate.org>
>> addNode(CLASS_LEVEL) is not a bad idea. The alternative is a full method
>> as proposed in BVAL-191.
>>
>> Unfortunately, we cannot solve the problem with this method because of
>> the second use case I describe in the email below. This example does not
>> work even if does not make use of addNode(null) :(
>>
>> Emmanuel
>>
>> On Wed 2012-12-05 14:10, Hardy Ferentschik wrote:
>> > Hi,
>> >
>> > Thanks for the clarification. Indeed I was forgetting about the special meaning of null in this case (should have read section 5.2 of the spec).
>> > In this context adding addNode(null) is indeed "natural" in the sense that it strictly follows the spec. That said, it still looks awkward to me.
>> > Couldn't there be for example a constant so that you could do something like addNode(CLASS_LEVEL). I find this much more telling.
>> > In this light option 4 - adding a different method - of your proposed solution on http://beanvalidation.org/proposals/BVAL-221/ sounds more appealing again.
>> > What about adding addClassLevelNode()?
>> >
>> > --Hardy
>> >
>> >
>> >
>> > On 4 Jan 2012, at 4:42 PM, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>> >
>> > > These are good questions
>> > >
>> > > ## Natural way to do it?
>> > >
>> > > Assuming
>> > >
>> > > @HasCorrectHomeAddressFromTop
>> > > class Order {
>> > > @HasCorrectHomeAddressFromUser
>> > > User user;
>> > > }
>> > >
>> > > class User {
>> > > @CollectionNotEmpty
>> > > @HasCorrectHomeAddressFromAddresses
>> > > Map<String,Address> addresses;
>> > > }
>> > >
>> > > When `HasCorrectHomeAddressFromTop` is validated, you can attach a
>> > > `ConstraintViolation` to Order.user.addresses["home"] with the
>> > > following call and it works in BV 1.0
>> > > This is how the API is supposed to be used.
>> > >
>> > > context.buildConstraintViolationWithTemplate( "Incorrect home address" )
>> > > .addNode( "user" )
>> > > .addNode( "addresses" )
>> > > .inIterable().atKey( "home" )
>> > > .addConstraintViolation();
>> > >
>> > > following this logic, when `HasCorrectHomeAddressFromUser` is validated,
>> > > you can attach a `ConstraintViolation` with the following call but that
>> > > does not work in BV 1.0.
>> > >
>> > > context.buildConstraintViolationWithTemplate( "Incorrect home address" )
>> > > .addNode( "addresses" )
>> > > .inIterable().atKey( "home" )
>> > > .addConstraintViolation();
>> > >
>> > > When `HasCorrectHomeAddressFromAddresses` is validated, you can attach a
>> > > `ConstraintViolation` with the following call but that does not work
>> > > in BV 1.0.
>> > >
>> > > context.buildConstraintViolationWithTemplate( "Incorrect home address" )
>> > > .addNode( null )
>> > > .inIterable().atKey( "home" )
>> > > .addConstraintViolation();
>> > >
>> > > Not that we use null as we add a class level constraint violation to the
>> > > element in `addresses["home"]`.
>> > >
>> > > For you info, when `CollectionNotEmpty` is validated, you can attach a
>> > > `ConstraintViolation` with the following call.
>> > >
>> > > context.buildConstraintViolationWithTemplate( "collection empty" )
>> > > .addConstraintViolation();
>> > >
>> > > ## Loss in type-safety
>> > >
>> > > If we add `inIterable()` to `NodeBuilderDefinedContext` we solve our
>> > > problem but we introduce a leak in the type safety. I could do the
>> > > following calls
>> > >
>> > > context.buildConstraintViolationWithTemplate( "Incorrect home address" )
>> > > .addNode( null )
>> > > .inIterable().atKey( "home" )
>> > > .inIterable().atKey( "wc" )
>> > > .addConstraintViolation();
>> > >
>> > > This call is not correct as no node has been (explicitly) created
>> > > between the two inIterable() calls. The correct call would be
>> > >
>> > > context.buildConstraintViolationWithTemplate( "Incorrect WC location" )
>> > > .addNode( null )
>> > > .inIterable().atKey( "home" )
>> > > .addNode( null )
>> > > .inIterable().atKey( "wc" )
>> > > .addConstraintViolation();
>> > >
>> > > Here we are assuming that the `addresses` elements contain map.
>> > >
>> > > We could add in the spec that subsequent calls to `inIterable()`
>> > > implicitly create a node without name.
>> > >
>> > > The problem is not as critical as I imagined but that would require
>> > > adding some magic rules wrt node creation.
>> > >
>> > > Also imagine a user willing to validate a property of Address, could he
>> > > forget to call the node creation method?
>> > >
>> > > Emmanuel
>> > >
>> > > On Mon 2012-11-26 13:07, Hardy Ferentschik wrote:
>> > >>
>> > >> On 23 Jan 2012, at 2:48 PM, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>> > >>
>> > >>> The question is do we want to do that or lean towards one of the
>> > >>> alternative methods:
>> > >>>
>> > >>> - an explicit new method deprecating addNode
>> > >>> - relaxing NodeBuilderDefinedContext and adding the new contract on it
>> > >>
>> > >> In the proposal you are saying about relaxing NodeBuilderDefinedContext: "But that would break the contextual
>> > >> and safety of the API as this interface is also returned by atKey and atIndex."
>> > >> Can you provide an example?
>> > >>
>> > >> Also in the proposal you are saying that:
>> > >>
>> > >> context.buildConstraintViolationWithTemplate("oh noes")
>> > >> .addNode(null) //ie the contained element
>> > >> inIterable().atKey(someKey)
>> > >> .addConstraintViolation();
>> > >>
>> > >> would be the natural solution. Why is ".addNode(null)" natural and why could we not have inIterable() directly
>> > >> on ConstraintViolationBuilder?
>> > >>
>> > >> --Hardy
>> > >>
>> > >>
>> > >> _______________________________________________
>> > >> beanvalidation-dev mailing list
>> > >> beanvalidation-dev at lists.jboss.org
>> > >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> > > _______________________________________________
>> > > beanvalidation-dev mailing list
>> > > beanvalidation-dev at lists.jboss.org
>> > > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> >
>> >
>> > _______________________________________________
>> > beanvalidation-dev mailing list
>> > beanvalidation-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20121207/de24828c/attachment-0001.html
More information about the beanvalidation-dev
mailing list