[hibernate-issues] [Hibernate-JIRA] Commented: (EJB-46) Property Validation should happen after PrePersist/PreUpdate

Brian Curnow (JIRA) noreply at atlassian.com
Tue Oct 31 13:32:07 EST 2006


    [ http://opensource.atlassian.com/projects/hibernate/browse/EJB-46?page=comments#action_25049 ] 

Brian Curnow commented on EJB-46:
---------------------------------

This issue (I think) is also affecting Id Classes. 

I have an Invoice class which contains a one to many relationship with InvoiceLine, InvoiceLine has a composite key made up of the Invoice Id (sequence generated) and the InvoiceLine Id. I'm using the @IdClass annotation and NOT embedded ids.

I'm trying to use @PostPersist on the Invoice object to update the InvoiceLines with the sequence generated Invoice id. However, it appears that Hibernate is creating the IdClass instance before I've had a chance to update the fields on InvoiceLine:

[DEBUG] AbstractSaveEventListener - generated identifier: component[invoiceId,invoiceLineId]{invoiceLineId=1, invoiceId=null}, using strategy: org.hibernate.id.Assigned

Therefore my @PostPersist method in Invoice has no affect because I can't change the value of invoiceId on the IdClass, only on the InvoiceLine.

If you think this is a separate issue let me know and I'll open another bug.

> Property Validation should happen after PrePersist/PreUpdate
> ------------------------------------------------------------
>
>          Key: EJB-46
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-46
>      Project: Hibernate Entity Manager
>         Type: Bug

>   Components: EntityManager
>     Versions: 3.1beta2, 3.1beta1
>  Environment: MySQL4, Sun JRE5, WinXP
>     Reporter: Johan Steiner
>  Attachments: EJB3EventListener.patch, EJB3EventListener_v2.patch
>
>
> Hi,
> the description is from http://forum.hibernate.org/viewtopic.php?t=944964 but I'm experiencing the exact same issue.
> *********************
> Hibernate does property validation such as not null checking before it does the EJB3 callback to prepersist/preupdate. I'm not sure if there's a good reason for this, but I think it would be particularly convenient if this behavior was reversed. IMHO it seems to better fit the semantics of the PRE callbacks, and it would allow callbacks to make modifications to the objects before they are persisted or updated -- modifications that might in turn effect the property validation Hibernate is doing.
> The "audit" example in the entity manager documentation does make changes to the object. What if these changes had effected the property validation done before the callback occurred? What if the object was in an invalid state before the callback, but a valid state after the callback? The latter case is what I think would be conveniently handled if hibernate did its property validation after prepersist/preupdate.
> Just two cents worth, obviously there are workarounds. This EJB3 stuff is looking great.
> Ryan
> P.S. This might also allow those of us who assign our own IDs to objects to do so automatically within a callback.
> *********************
> In my case I'm working with an entity like:
> public class MyEntity
> {
> 	@Basic(temporalType = TemporalType.TIMESTAMP)
> 	@Column(name = "$createdOn", insertable = true, updatable = false, nullable = false)
> 	private Date firstPersistedOn = null;
> 	@Basic(temporalType = TemporalType.TIMESTAMP)
> 	@Column(name = "$modifiedOn", insertable = true, updatable = false, nullable = true)
> 	private Date lastPersistedOn = null;
> 	@PrePersist
> 	public void onPrePersist()
> 	{
> 		firstPersistedOn = new Date();
> 	}
> 	@PreUpdate
> 	public void onPreUpdate()
> 	{
> 		lastPersistedOn = new Date();
> 	}
> }
> Hibernate throws:
> org.hibernate.PropertyValueException: not-null property references a null or transient value: MyEntity.firstPersistedOn
> 	at org.hibernate.engine.Nullability.checkNullability(Nullability.java:72)
> 	at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:262)
> 	at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:164)
> 	at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:114)
> 	at org.hibernate.event.def.DefaultMergeEventListener.entityIsTransient(DefaultMergeEventListener.java:167)
> 	at org.hibernate.event.def.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:113)
> 	at org.hibernate.event.def.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:60)
> 	at org.hibernate.impl.SessionImpl.merge(SessionImpl.java:540)
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:139)
> Regards,
> Johan

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira




More information about the hibernate-issues mailing list