1:33 a.m.
2012/5/21 Emmanuel Bernard <emmanuel(a)hibernate.org>:
On 21 mai 2012, at 21:06, Gunnar Morling wrote:
> 2012/5/21 Emmanuel Bernard <emmanuel(a)hibernate.org>:
>>
>> On 15 mai 2012, at 19:50, Gunnar Morling wrote:
>>
>>> I also find disabling validation of @NotNull by default problematic.
>>> If I'm for instance using sequences for id generation, then @NotNull
>>> should be validated upon insertion. But relying on sequences is IMO
>>> per se not portable; so when deciding to use them, I'd also expect
>>> @NotNull to be validated.
>>
>> I think you misunderstood something. If sequence, table generation or
any
in memory generation logic is used, then @NoNull will indeed be
validated in option #3. In fact, database trigger and column id generations
are the only one that would disable validation.
>
> Ah, I see. Indeed I thought that you meant to disable validation of
> @NotNull in any case. If the behavior depends on the applied id
> generation strategy, #3 makes more sense.
>
> I'm not sure, does the JPA spec define that sequence values are always
> to be prefetched? Otherwise I could imagine situations where an
> allocation size of 1 is used, which would allow to fetch the sequence
> just within the INSERT statement. In that case I think the constraints
> again couldn't be validated.
The JPA provider implementation would know such thing and act accordingly.
Right. I guess what I'm just not totally comfortable with is the fact that,
when looking at an entity, it gets a bit more complicated to understand
whether a @NotNull constraint is validated or not.
By defining a validation group such as @PreUpdate and putting the @NotNull
constraint into that group a user could solve the issue in an
easy-to-understand way leveraging the existing mechanisms.
I see that such a feature would probably help to give a better
"it-just-works" experience. But one could also argue that using a sequence
(or another id generation strategy not providing a value before the insert)
and a @NotNull constraint within a group which is validated upon insertion
represents an inconsistency within the data model.
On a more practical side: How would a JPA provider implement that feature?
The simplest would probably be to validate all constraints and then ignore
any id-related violations based on the chosen generation strategy. Or do
you think we should define a way to control whether certain constraints are
to be excluded by the BV runtime?
--Gunnar
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
3:54 a.m.
New subject: BVAL-234 @NotNull @Id for JPA and Bean Validation
I agree with Gunnar. I still find it too much magic. Working with groups seems better.
--Hardy
On May 22, 2012, at 8:33 AM, Gunnar Morling wrote:
Right. I guess what I'm just not totally comfortable with is the
fact that, when looking at an entity, it gets a bit more complicated to understand whether
a @NotNull constraint is validated or not.
By defining a validation group such as @PreUpdate and putting the @NotNull constraint
into that group a user could solve the issue in an easy-to-understand way leveraging the
existing mechanisms.
I see that such a feature would probably help to give a better "it-just-works"
experience. But one could also argue that using a sequence (or another id generation
strategy not providing a value before the insert) and a @NotNull constraint within a group
which is validated upon insertion represents an inconsistency within the data model.
9:10 a.m.
New subject: BVAL-234 @NotNull @Id for JPA and Bean Validation
On 22 mai 2012, at 08:33, Gunnar Morling wrote:
Right. I guess what I'm just not totally comfortable with is the
fact that, when looking at an entity, it gets a bit more complicated to understand whether
a @NotNull constraint is validated or not.
By defining a validation group such as @PreUpdate and putting the @NotNull constraint
into that group a user could solve the issue in an easy-to-understand way leveraging the
existing mechanisms.
I see that such a feature would probably help to give a better "it-just-works"
experience. But one could also argue that using a sequence (or another id generation
strategy not providing a value before the insert) and a @NotNull constraint within a group
which is validated upon insertion represents an inconsistency within the data model.
On a more practical side: How would a JPA provider implement that feature? The simplest
would probably be to validate all constraints and then ignore any id-related violations
based on the chosen generation strategy. Or do you think we should define a way to control
whether certain constraints are to be excluded by the BV runtime?
I understand we are talking about a trade-off between a bit of magic vs usability. We all
know Bean Validation pretty well and in 10 mins we know that using a group can work around
that. I could understand the full problem in 15 mins because I happen to be in both the
JPA and the BV expert group. But how long would it have taken you? The NetBeans team got
it backwards for example.
Think about regular developers, they probably don't really know that an id can be
populated after the object is saved in the database. So when they see such an exception
popping up, they expect a bug in either the JPA or Bean Validation provider. Once they
realize it might not be a bug, they have to find out the fairly verbose workaround.
With option #3, the issue is silently ignored. Is that bad? My claim is that it is not bad
because the value is generated anyways and the probability of having a erroneous
constraint is low. And as Sebastien proposed we could do a post-create checking for the id
property and give the feedback to the user.
I don't want to see a blog post down the line claiming that Java EE designers are
stupid morons not to take care of such trivial issue and have them explaining why platform
X or Y is better because of those details.
About the implementation, the JPA provider would pass a custom TraversableResolver that
would return false to isReachable(…) when the node is the identifier property of the
entity instance.
9:26 a.m.
New subject: BVAL-234 @NotNull @Id for JPA and Bean Validation
On May 22, 2012, at 7:11, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
Think about regular developers, they probably don't really know
that an id can be populated after the object is saved in the database. So when they see
such an exception popping up, they expect a bug in either the JPA or Bean Validation
provider. Once they realize it might not be a bug, they have to find out the fairly
verbose workaround.
With option #3, the issue is silently ignored. Is that bad? My claim is that it is not
bad because the value is generated anyways and the probability of having a erroneous
constraint is low. And as Sebastien proposed we could do a post-create checking for the id
property and give the feedback to the user.
I've been watching this conversation because I myself have just
created a project with several @Generated @Ids on which I can't use
@NotNull. At first I thought #3 (w/ TraversableResolver) was the more
elegant solution. But then I remembered that many projects (such as
mine) don't *rely* on the JPA provider invoking validations. In fact,
doing so causes problems because the exceptions can occur at
unexpected times and it becomes very difficult (for a web app) to
highlight invalid fields when the propertyPaths are relative to an
arbitrary root. My point is, we rely mostly on invoking validation
from the service layer (manually or with method validation / AOP via
Spring). JPA validation provides a comfortable last-chance sanity
check and a convenient way to map @NotNull to @Column(nullable=false).
So a TraversableResolver would be useless to my projects and we'd have
to use groups anyway.
Thanks,
Peter Davis
10:05 a.m.
New subject: BVAL-234 @NotNull @Id for JPA and Bean Validation
On 22 mai 2012, at 16:26, Peter Davis wrote:
On May 22, 2012, at 7:11, Emmanuel Bernard
<emmanuel(a)hibernate.org> wrote:
> Think about regular developers, they probably don't really know that an id can be
populated after the object is saved in the database. So when they see such an exception
popping up, they expect a bug in either the JPA or Bean Validation provider. Once they
realize it might not be a bug, they have to find out the fairly verbose workaround.
>
> With option #3, the issue is silently ignored. Is that bad? My claim is that it is
not bad because the value is generated anyways and the probability of having a erroneous
constraint is low. And as Sebastien proposed we could do a post-create checking for the id
property and give the feedback to the user.
I've been watching this conversation because I myself have just
created a project with several @Generated @Ids on which I can't use
@NotNull. At first I thought #3 (w/ TraversableResolver) was the more
elegant solution. But then I remembered that many projects (such as
mine) don't *rely* on the JPA provider invoking validations. In fact,
doing so causes problems because the exceptions can occur at
unexpected times and it becomes very difficult (for a web app) to
highlight invalid fields when the propertyPaths are relative to an
arbitrary root. My point is, we rely mostly on invoking validation
from the service layer (manually or with method validation / AOP via
Spring). JPA validation provides a comfortable last-chance sanity
check and a convenient way to map @NotNull to @Column(nullable=false).
So a TraversableResolver would be useless to my projects and we'd have
to use groups anyway.
It depends what your AOP layer is doing. If it executes validation before the transaction
is committed - or before flush() is called - then yes, you need groups. But I don't
see your APO layer validating newly created and stored objects. Can you detail your use
case where you would end up in the situation we are discussing.
4601
days inactive
4601
days old
beanvalidation-dev@lists.jboss.org
4 comments
4 participants
participants (4)
-
Emmanuel Bernard -
Gunnar Morling -
Hardy Ferentschik -
Peter Davis