Menu
▾
▴
hibernate-issues
|
From: <no...@at...> - 2005-08-07 17:18:01
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/browse/EJB-46 Here is an overview of the issue: --------------------------------------------------------------------- Key: EJB-46 Summary: Property Validation should happen after PrePersist/PreUpdate Type: Bug Status: Unassigned Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: Hibernate Entity Manager Components: EntityManager Versions: 3.1beta1 3.1beta2 Assignee: Reporter: Johan Steiner Created: Sun, 7 Aug 2005 12:17 PM Updated: Sun, 7 Aug 2005 12:17 PM Environment: MySQL4, Sun JRE5, WinXP Description: 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 --------------------------------------------------------------------- JIRA INFORMATION: 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 If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: Grant Q. (JIRA) <no...@at...> - 2006-05-12 00:35:16
|
[ http://opensource.atlassian.com/projects/hibernate/browse/EJB-46?page=comments#action_23086 ] Grant Quimby commented on EJB-46: --------------------------------- Hi, This is also a problem with with my current project. And is also located at http://jira.jboss.com/jira/browse/EJBTHREE-553 Anybody know of any fixes or workarounds. Thanks Grant > 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 > > > 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 |
|
From: <no...@at...> - 2006-05-13 22:01:21
|
[ http://opensource.atlassian.com/projects/hibernate/browse/EJB-46?pag= e=3Dall ] Micha=C5=82 Borowiecki updated EJB-46: --------------------------------- Attachment: EJB3EventListener.patch ebj3 event listeners currently perform lifecycle callbacks in the overriden= invokeSaveLifecycle method, which is only invoked after validation has suc= ceeded. I moved the callback invocation before validation by overriding the= saveWithGeneratedId method. This seems to have fixed the issue. I attach t= he patch. From what I could determine: The EJB3PersistEventListener is invoked when an enitity is persisted by a c= all to EntityManager.persist The EJB3MergeEventListener is invoked when an entity is persisted by a call= to EntityManager.merge on some other entity which has been set to cascade = on its relationship. I've also modified EJB3SaveEventListener and EJB3SaveOrUpdateEventListener = although I couldn't find the circumstances when they're used. However, sinc= e they all subclass AbstractSaveEventListener I figured it is better to mod= ify them accordingly.=20 Also I have overriden the saveWithRequestedId method on all four classes, a= lthough again I couldn't establish when the method is called. As for the PreUpdate callback I think it is called before validation, as it= should be. I set a non-nullible field to null, call merge on the entity and only set t= he field to a non-null value in PreUpdate and it works.=20 I did however find a bug in DefaultFlushEntityEventListener that is related= , in that it also stems from the assumption that the callbacks do not alter= the entity's persistant state. I will create a new issue for it. > Property Validation should happen after PrePersist/PreUpdate > ------------------------------------------------------------ > > Key: EJB-46 > URL: http://opensource.atlassian.com/projects/hibernate/browse/E= JB-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 > > > Hi, > the description is from http://forum.hibernate.org/viewtopic.php?t=3D9449= 64 but I'm experiencing the exact same issue. > ********************* > Hibernate does property validation such as not null checking before it do= es the EJB3 callback to prepersist/preupdate. I'm not sure if there's a goo= d 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 objec= ts 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 sta= te before the callback, but a valid state after the callback? The latter ca= se is what I think would be conveniently handled if hibernate did its prope= rty 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 > { > =09@Basic(temporalType =3D TemporalType.TIMESTAMP) > =09@Column(name =3D "$createdOn", insertable =3D true, updatable =3D fals= e, nullable =3D false) > =09private Date firstPersistedOn =3D null; > =09@Basic(temporalType =3D TemporalType.TIMESTAMP) > =09@Column(name =3D "$modifiedOn", insertable =3D true, updatable =3D fal= se, nullable =3D true) > =09private Date lastPersistedOn =3D null; > =09@PrePersist > =09public void onPrePersist() > =09{ > =09=09firstPersistedOn =3D new Date(); > =09} > =09@PreUpdate > =09public void onPreUpdate() > =09{ > =09=09lastPersistedOn =3D new Date(); > =09} > } > Hibernate throws: > org.hibernate.PropertyValueException: not-null property references a null= or transient value: MyEntity.firstPersistedOn > =09at org.hibernate.engine.Nullability.checkNullability(Nullability.java:= 72) > =09at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrRepl= icate(AbstractSaveEventListener.java:262) > =09at org.hibernate.event.def.AbstractSaveEventListener.performSave(Abstr= actSaveEventListener.java:164) > =09at org.hibernate.event.def.AbstractSaveEventListener.saveWithGenerated= Id(AbstractSaveEventListener.java:114) > =09at org.hibernate.event.def.DefaultMergeEventListener.entityIsTransient= (DefaultMergeEventListener.java:167) > =09at org.hibernate.event.def.DefaultMergeEventListener.onMerge(DefaultMe= rgeEventListener.java:113) > =09at org.hibernate.event.def.DefaultMergeEventListener.onMerge(DefaultMe= rgeEventListener.java:60) > =09at org.hibernate.impl.SessionImpl.merge(SessionImpl.java:540) > =09at org.hibernate.ejb.AbstractEntityManagerImpl.merge(AbstractEntityMan= agerImpl.java:139) > Regards, > Johan --=20 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 |
|
From: <no...@at...> - 2006-05-13 22:37:11
|
[ http://opensource.atlassian.com/projects/hibernate/browse/EJB-46?page= =3Dcomments#action_23096 ]=20 Micha=C5=82 Borowiecki commented on EJB-46: -------------------------------------- The PreUpdate bug I referred to earlier is now EJB-180. > Property Validation should happen after PrePersist/PreUpdate > ------------------------------------------------------------ > > Key: EJB-46 > URL: http://opensource.atlassian.com/projects/hibernate/browse/E= JB-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 > > > Hi, > the description is from http://forum.hibernate.org/viewtopic.php?t=3D9449= 64 but I'm experiencing the exact same issue. > ********************* > Hibernate does property validation such as not null checking before it do= es the EJB3 callback to prepersist/preupdate. I'm not sure if there's a goo= d 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 objec= ts 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 sta= te before the callback, but a valid state after the callback? The latter ca= se is what I think would be conveniently handled if hibernate did its prope= rty 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 > { > =09@Basic(temporalType =3D TemporalType.TIMESTAMP) > =09@Column(name =3D "$createdOn", insertable =3D true, updatable =3D fals= e, nullable =3D false) > =09private Date firstPersistedOn =3D null; > =09@Basic(temporalType =3D TemporalType.TIMESTAMP) > =09@Column(name =3D "$modifiedOn", insertable =3D true, updatable =3D fal= se, nullable =3D true) > =09private Date lastPersistedOn =3D null; > =09@PrePersist > =09public void onPrePersist() > =09{ > =09=09firstPersistedOn =3D new Date(); > =09} > =09@PreUpdate > =09public void onPreUpdate() > =09{ > =09=09lastPersistedOn =3D new Date(); > =09} > } > Hibernate throws: > org.hibernate.PropertyValueException: not-null property references a null= or transient value: MyEntity.firstPersistedOn > =09at org.hibernate.engine.Nullability.checkNullability(Nullability.java:= 72) > =09at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrRepl= icate(AbstractSaveEventListener.java:262) > =09at org.hibernate.event.def.AbstractSaveEventListener.performSave(Abstr= actSaveEventListener.java:164) > =09at org.hibernate.event.def.AbstractSaveEventListener.saveWithGenerated= Id(AbstractSaveEventListener.java:114) > =09at org.hibernate.event.def.DefaultMergeEventListener.entityIsTransient= (DefaultMergeEventListener.java:167) > =09at org.hibernate.event.def.DefaultMergeEventListener.onMerge(DefaultMe= rgeEventListener.java:113) > =09at org.hibernate.event.def.DefaultMergeEventListener.onMerge(DefaultMe= rgeEventListener.java:60) > =09at org.hibernate.impl.SessionImpl.merge(SessionImpl.java:540) > =09at org.hibernate.ejb.AbstractEntityManagerImpl.merge(AbstractEntityMan= agerImpl.java:139) > Regards, > Johan --=20 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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X