10:22 a.m.
There is an annoyance when using JPA and Bean Validation today. I worked out a proposal.
Please let me know what you think
http://beanvalidation.org/proposals/BVAL-234/
--- (copied here for convenience) ---
[Link to JIRA ticket][jira]
See also [NetBeans issue][netbeans]
## Problem description
Today when a property marked @Id @GeneratedValue is also marked @NotNull, it will fail if
the identity generation is post-insert
in the database. This can be the case if the underlying table is using column id
generation for example.
The id property is thus null when Bean Validation is executed during the pre-persist phase
and a constraint
violation is raised.
## Solutions
### 1. User adjusts
One option is to stay put and consider the behavior valid. The user can work around that
by:
- creating a `com.acme.groups.Created` group
- marking the `@NotNull` annotation as belonging to the group
- override the groups in `persistence.xml` to validate `Created` accordingly
Here is the snipped of the `persistence.xml` file
<property name="javax.persistence.validation.group.pre-persist"
value="javax.validation.groups.Default"/>
<property name="javax.persistence.validation.group.pre-update"
value="javax.validation.groups.Default,com.acme.groups.Created"/>
### 2 User adjusts with some help
We could use option 1 but have JPA provide the created group:
`javax.persistence.validation.groups.Created`
### 3. Have JPA disable validation of id properties at pre-persist
JPA could disable validation on id properties if in pre-persist and if the generated value
is not created yet.
Note that we disable all validations - not simply `@NotNull` - as it does not make much
sense to execute other
validations when a property is null.
`TraversableResolver` can be used to solve the problem as `isReachable` can stop the
processing of a property.
### Conclusions
Option 3 seems the most reasonable but it could be complicated at the JPA level.
Before going to the JPA EG, let's discuss the situation here.
### Questions remaining
- should the `Created` groups be renamed?
- is that correct to sneakily disable @NotNull constraint validation?
[netbeans]: http://netbeans.org/bugzilla/show_bug.cgi?id=197845#c3
[jira]: https://hibernate.onjira.com/browse/BVAL-234
11:57 a.m.
I would prefer option 3 if possible. But would this require XA
transactions (two phase commit) because JPA would trigger the ID
validation after the record has been created and if invalid needs to
rollback the commit.
Seb
On 15.05.2012 10:22, Emmanuel Bernard wrote:
There is an annoyance when using JPA and Bean Validation today. I
worked out a proposal. Please let me know what you think
http://beanvalidation.org/proposals/BVAL-234/
--- (copied here for convenience) ---
[Link to JIRA ticket][jira]
See also [NetBeans issue][netbeans]
## Problem description
Today when a property marked @Id @GeneratedValue is also marked @NotNull, it will fail if
the identity generation is post-insert
in the database. This can be the case if the underlying table is using column id
generation for example.
The id property is thus null when Bean Validation is executed during the pre-persist
phase and a constraint
violation is raised.
## Solutions
### 1. User adjusts
One option is to stay put and consider the behavior valid. The user can work around that
by:
- creating a `com.acme.groups.Created` group
- marking the `@NotNull` annotation as belonging to the group
- override the groups in `persistence.xml` to validate `Created` accordingly
Here is the snipped of the `persistence.xml` file
<property name="javax.persistence.validation.group.pre-persist"
value="javax.validation.groups.Default"/>
<property name="javax.persistence.validation.group.pre-update"
value="javax.validation.groups.Default,com.acme.groups.Created"/>
### 2 User adjusts with some help
We could use option 1 but have JPA provide the created group:
`javax.persistence.validation.groups.Created`
### 3. Have JPA disable validation of id properties at pre-persist
JPA could disable validation on id properties if in pre-persist and if the generated
value is not created yet.
Note that we disable all validations - not simply `@NotNull` - as it does not make much
sense to execute other
validations when a property is null.
`TraversableResolver` can be used to solve the problem as `isReachable` can stop the
processing of a property.
### Conclusions
Option 3 seems the most reasonable but it could be complicated at the JPA level.
Before going to the JPA EG, let's discuss the situation here.
### Questions remaining
- should the `Created` groups be renamed?
- is that correct to sneakily disable @NotNull constraint validation?
[netbeans]: http://netbeans.org/bugzilla/show_bug.cgi?id=197845#c3
[jira]: https://hibernate.onjira.com/browse/BVAL-234
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
12:38 p.m.
Is option #3 even possible within the JPA spec? One would need meta information about the
id property
(which generation type and how exactly this type behaves regarding the id generation
time). I don't think there
is a way to do this with the JPA api. Also JPA does not even explicitly define the
behavior of the different strategies.
Disabling the validation per default can also backfire in the cases where a user
"knows" that a certain strategy
will generate the id pre insert. In this case it would be valid to add @NotNull.
To me option #1 sounds best. Maybe #2, but I am not convinced that it is needed.
--Hardy
On May 15, 2012, at 10:22 AM, Emmanuel Bernard wrote:
There is an annoyance when using JPA and Bean Validation today. I
worked out a proposal. Please let me know what you think
http://beanvalidation.org/proposals/BVAL-234/
--- (copied here for convenience) ---
[Link to JIRA ticket][jira]
See also [NetBeans issue][netbeans]
## Problem description
Today when a property marked @Id @GeneratedValue is also marked @NotNull, it will fail if
the identity generation is post-insert
in the database. This can be the case if the underlying table is using column id
generation for example.
The id property is thus null when Bean Validation is executed during the pre-persist
phase and a constraint
violation is raised.
## Solutions
### 1. User adjusts
One option is to stay put and consider the behavior valid. The user can work around that
by:
- creating a `com.acme.groups.Created` group
- marking the `@NotNull` annotation as belonging to the group
- override the groups in `persistence.xml` to validate `Created` accordingly
Here is the snipped of the `persistence.xml` file
<property name="javax.persistence.validation.group.pre-persist"
value="javax.validation.groups.Default"/>
<property name="javax.persistence.validation.group.pre-update"
value="javax.validation.groups.Default,com.acme.groups.Created"/>
### 2 User adjusts with some help
We could use option 1 but have JPA provide the created group:
`javax.persistence.validation.groups.Created`
### 3. Have JPA disable validation of id properties at pre-persist
JPA could disable validation on id properties if in pre-persist and if the generated
value is not created yet.
Note that we disable all validations - not simply `@NotNull` - as it does not make much
sense to execute other
validations when a property is null.
`TraversableResolver` can be used to solve the problem as `isReachable` can stop the
processing of a property.
### Conclusions
Option 3 seems the most reasonable but it could be complicated at the JPA level.
Before going to the JPA EG, let's discuss the situation here.
### Questions remaining
- should the `Created` groups be renamed?
- is that correct to sneakily disable @NotNull constraint validation?
[netbeans]: http://netbeans.org/bugzilla/show_bug.cgi?id=197845#c3
[jira]: https://hibernate.onjira.com/browse/BVAL-234
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
1:23 p.m.
I was not thinking of validating the object id property after it has been inserted but
simply avoid validation in pre-persist altogether.
We could try and see if your approach is feasible indeed but the benefit would be quite
minimal as we are talking about a generated id.
You don't need 2 PC, id generation is still done within the same transaction - at
flush time to be specific. Insertion out of transaction
is not possible in JPA.
On 15 mai 2012, at 11:57, Sebastian Thomschke wrote:
I would prefer option 3 if possible. But would this require XA
transactions (two phase commit) because JPA would trigger the ID
validation after the record has been created and if invalid needs to
rollback the commit.
Seb
On 15.05.2012 10:22, Emmanuel Bernard wrote:
> There is an annoyance when using JPA and Bean Validation today. I worked out a
proposal. Please let me know what you think
>
> http://beanvalidation.org/proposals/BVAL-234/
>
> --- (copied here for convenience) ---
>
> [Link to JIRA ticket][jira]
> See also [NetBeans issue][netbeans]
>
> ## Problem description
>
> Today when a property marked @Id @GeneratedValue is also marked @NotNull, it will
fail if the identity generation is post-insert
> in the database. This can be the case if the underlying table is using column id
generation for example.
>
> The id property is thus null when Bean Validation is executed during the pre-persist
phase and a constraint
> violation is raised.
>
> ## Solutions
>
> ### 1. User adjusts
>
> One option is to stay put and consider the behavior valid. The user can work around
that by:
>
> - creating a `com.acme.groups.Created` group
> - marking the `@NotNull` annotation as belonging to the group
> - override the groups in `persistence.xml` to validate `Created` accordingly
>
> Here is the snipped of the `persistence.xml` file
>
> <property name="javax.persistence.validation.group.pre-persist"
> value="javax.validation.groups.Default"/>
> <property name="javax.persistence.validation.group.pre-update"
>
value="javax.validation.groups.Default,com.acme.groups.Created"/>
>
>
> ### 2 User adjusts with some help
>
> We could use option 1 but have JPA provide the created group:
`javax.persistence.validation.groups.Created`
>
> ### 3. Have JPA disable validation of id properties at pre-persist
>
> JPA could disable validation on id properties if in pre-persist and if the generated
value is not created yet.
> Note that we disable all validations - not simply `@NotNull` - as it does not make
much sense to execute other
> validations when a property is null.
>
> `TraversableResolver` can be used to solve the problem as `isReachable` can stop the
processing of a property.
>
> ### Conclusions
>
> Option 3 seems the most reasonable but it could be complicated at the JPA level.
> Before going to the JPA EG, let's discuss the situation here.
>
> ### Questions remaining
>
> - should the `Created` groups be renamed?
> - is that correct to sneakily disable @NotNull constraint validation?
>
>
> [netbeans]: http://netbeans.org/bugzilla/show_bug.cgi?id=197845#c3
> [jira]: https://hibernate.onjira.com/browse/BVAL-234
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
1:25 p.m.
On 15 mai 2012, at 12:38, Hardy Ferentschik wrote:
Is option #3 even possible within the JPA spec? One would need meta
information about the id property
(which generation type and how exactly this type behaves regarding the id generation
time). I don't think there
is a way to do this with the JPA api. Also JPA does not even explicitly define the
behavior of the different strategies.
Remember that the TraversableResolver used in pre-* events is implemented by the JPA
provider itself. It's very easy for the implementation
to tap provider specific metadata (most likely not exposed). We don't need JPA to
expose the API.
Disabling the validation per default can also backfire in the cases where a user
"knows" that a certain strategy
will generate the id pre insert. In this case it would be valid to add @NotNull.
True but that would definitely make the application non portable from a JPA point of
view.
7:50 p.m.
2012/5/15 Emmanuel Bernard <emmanuel(a)hibernate.org>:
On 15 mai 2012, at 12:38, Hardy Ferentschik wrote:
> Is option #3 even possible within the JPA spec? One would need meta information about
the id property
> (which generation type and how exactly this type behaves regarding the id generation
time). I don't think there
> is a way to do this with the JPA api. Also JPA does not even explicitly define the
behavior of the different strategies.
Remember that the TraversableResolver used in pre-* events is implemented by the JPA
provider itself. It's very easy for the implementation
to tap provider specific metadata (most likely not exposed). We don't need JPA to
expose the API.
>
> Disabling the validation per default can also backfire in the cases where a user
"knows" that a certain strategy
> will generate the id pre insert. In this case it would be valid to add @NotNull.
True but that would definitely make the application non portable from a JPA point of
view.
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'm in favor of option #1; users can precisely configure the behavior
they need with the existing constructs (validation groups), so I don't
really see the need for adding something to the spec.
Regarding #2, I'm not sure whether that offers much value. But if
going down that road, I think I'd do it consequently and introduce
@PreInsert, @PreUpdate and @PreDelete.
--Gunnar
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
12:32 p.m.
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.
9:06 p.m.
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.
--Gunnar
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
9:51 p.m.
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.
4351
days inactive
4357
days old
beanvalidation-dev@lists.jboss.org
8 comments
4 participants
participants (4)
-
Emmanuel Bernard -
Gunnar Morling -
Hardy Ferentschik -
Sebastian Thomschke