[bv-dev] Feature Suggestion :: Implicit constraints

Tue Jul 29 12:09:28 EDT 2014

I don't think this use case is so uncommon. I was doing this years ago with
custom extensions to Apache BVal. I suppose there is no reason one couldn't
generate XML in response to a reflective examination of a set of classes
and bootstrap a validator using the result, but that does seem cumbersome
compared to a custom API.

Matt

On Tue, Jul 29, 2014 at 11:01 AM, Richard Fanning <
Richard.Fanning at fineos.com> wrote:

>  Hi guys,
>
>
>
> Thanks for the responses. You’re probably both correct in that this is an
> uncommon use case..
>
>
>
> Another scenario in our company where we thought this feature might be
> useful was again around the area of defaults. So for example a String
> property on an @Entity would not need to define any @Size but a sensible
> default (255) would apply akin to JPA providers [1]
>
>
>
> But we’d still like to get ConstraintViolations during validation phase
> rather than some JPA/DB errors complaining about the strings length.
>
>
>
> Anywho using the programmatic HV API is certainly a better approach than
> “hacking my into the guts of HV” albeit they pretty well organized guts J
>
>
>
> I guess a take away for the Bean Validations EG might be that the HV
> programmatic constraints API has it’s uses and would be useful as part of
> JSR SPEC.
>
>
>
> Thanks for your time.
>
>
>
> Rich
>
>
>
> [1]
> http://stackoverflow.com/questions/7509769/how-to-increase-length-of-a-string-in-mysql-while-mapping-using-jpa
>
>
>
>
>
> *From:* beanvalidation-dev-bounces at lists.jboss.org [mailto:
> beanvalidation-dev-bounces at lists.jboss.org] *On Behalf Of *Gunnar Morling
> *Sent:* 29 July 2014 14:53
> *To:* beanvalidation-dev List
> *Subject:* Re: [bv-dev] Feature Suggestion :: Implicit constraints
>
>
>
> Hi,
>
>
>
> 2014-07-29 15:31 GMT+02:00 Richard Fanning <Richard.Fanning at fineos.com>:
>
>  Hi there,
>
>
>
> We are starting to use bean validation in our product and something we
> would like to do is what I’ve coined as “implicit constraints”. I’d like to
> run this by the mailing list and get your thoughts on this as a potential
> feature in the spec.
>
>
>
> The use case we have is we have a “DateTime” object which represents Date
> & Time. Our DateTime object pre-dates JDK 8 (and JodaTime).  A DateTime for
> us has some constraints
>
>
>
> 1.       The DateTime cannot me before LOW_DATE à 01-01-1970 00:00:00
>
> 2.       The DateTime cannot me after HIGH_DATE à 31-12-2150 23:59:59
>
>
>
> Not sure of the exact history of these constraints but it would seem like
> we are trying to invent a new y2k J
>
>
>
> These constraints were enforced prior to our usage of Bean Validation as
> these were burnt into the setter of generated POJO’s (domain objects) but
> now that we are moving from generated domain objects to JPA style POJO’s
> we’d like to use Bean Validation to apply the same constraints.
>
>   Assume we have an object which has a DateTime property as shown below
>
>
>
> *public* *class* TestObject {
>
>
>
>         *private* DateTime myDateTime;
>
>
>
>         *public* DateTime getMyDateTime() {
>
>                 *return* myDateTime;
>
>         }
>
>
>
>         *public* *void* setMyDateTime(DateTime myDateTime) {
>
>                 *this*.myDateTime = myDateTime;
>
>         }
>
>
>
> }
>
>
>
> We’d like if developers did not need to add an annotation all DateTime
> properties to constrain with the implicit constraints.. i.e.
>
>
>
> @Date
>
> *private* DateTime myDateTime;
>
>
>
> In our opinion this annotation serves no additional purpose and would be
> an extra onus on the developer to add this so they ensure the value meets
> internal DateTime criteria.
>
>
>
> Looking at the 1.1 spec I cannot see any way of applying constraints
> without annotating (well you can use HV XML but that would need to be done
> for all fields).. Is that correct.
>
>
>
> Yes, the spec defines constraint declaration via annotations and XML.
> Hibernate Validator in addition has a (public) API for programmatic
> constraint declaration.
>
>
>
> I’ve managed to implement “implicit constraints” by using non-standard
> Hibernate Validator API’s (i.e. using reflection I added an additional
> MetaDataProvider which added ConstrainedElements ( to the
> BeanConfiguration)). I can share this on GitHub is anyone is interested in
> taking a look.
>
>
>
> You should better use the HV constraint API for this [1]. You could
> inspect your beans using reflection and define a @Date constraint for each
> DateTime property you find. MetaDataProvider et al. are internal APIs which
> may change without notice between releases.
>
>
>
> Standardizing this API might be a useful addition as it allows to
> implement cases as yours in a portable manner. Not sure whether the spec
> should explicitly support this requirement, as it may be very specific.
>
>
>
>  Appreciate any feedback you might have.
>
>
>
> Thanks
>
>
> Rich
>
>
>
> --Gunnar
>
>
>
> [1]
> http://docs.jboss.org/hibernate/validator/5.1/reference/en-US/html_single/#section-programmatic-api
>
>
>
>
>
>
>
> __________________________________________________________
> FINEOS Corporation is the global brand name of FINEOS Corporation and its
> affiliated
> group companies worldwide.
>
> The information contained in this e-mail is confidential, may be
> privileged and is intended
> only for the use of the recipient named above. If you are not the intended
> recipient or a
> representative of the intended recipient, you have received this e-mail in
> error and must
> not copy, use or disclose the contents of this e-mail to anybody else.
>
> If you have received this e-mail in error, please notify the sender
> immediately by return
> e-mail and permanently delete the copy you received.  This e-mail has been
> swept for
> computer viruses. However, you should carry out your own virus checks.
> Registered in Ireland, No. 205721.  http://www.FINEOS.com
> __________________________________________________________
>
>
> _______________________________________________
> 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/20140729/673af11b/attachment-0001.html 