[Hibernate-JIRA] Updated: (EJB-46) Property Validation should happen after PrePersist/PreUpdate
by Emmanuel Bernard (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/EJB-46?page=all ]
Emmanuel Bernard updated EJB-46:
--------------------------------
Fix Version: 3.2.2
> 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.1beta1, 3.1beta2
> Environment: MySQL4, Sun JRE5, WinXP
> Reporter: Johan Steiner
> Fix For: 3.2.2
> 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....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
17 years, 11 months
[Hibernate-JIRA] Resolved: (ANN-252) AnnotationConfiguration silently ignores classes that are annotated with wrong Entity, or not annotated.
by Emmanuel Bernard (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/ANN-252?page=all ]
Emmanuel Bernard resolved ANN-252:
----------------------------------
Fix Version: 3.2.2
Resolution: Fixed
Assign To: Emmanuel Bernard (was: Max Rydahl Andersen)
Partial safety net, will not work when used as a JPA provider (see explainations above)
> AnnotationConfiguration silently ignores classes that are annotated with wrong Entity, or not annotated.
> --------------------------------------------------------------------------------------------------------
>
> Key: ANN-252
> URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-252
> Project: Hibernate Annotations
> Type: Improvement
> Components: binder
> Versions: 3.1beta8
> Reporter: Damon Feldman
> Assignee: Emmanuel Bernard
> Fix For: 3.2.2
>
> Original Estimate: 1 hour
> Remaining: 1 hour
>
> If you import the wrong Entity (e.g. org.hibernate.annotation.Entity) in a persistent class, the class is ignored, but no logging or other notification is made of the issue.
> Recommend: adding a log statement:
> log.warn("The class" + annotatedClass.getName() +"does not have the proper annotation: " + Entity.class.getName());
> Here is the code that seems responsible:
> /**
> * Read a mapping from the class annotation metadata (JSR 175).
> *
> * @param persistentClass the mapped class
> * @return the configuration object
> */
> public AnnotationConfiguration addAnnotatedClass(Class persistentClass) throws MappingException {
> try {
> if ( persistentClass.isAnnotationPresent( Entity.class ) ) {
> annotatedClassEntities.put( persistentClass.getName(), persistentClass );
> }
> annotatedClasses.add( persistentClass );
> return this;
> }
> catch (MappingException me) {
> log.error( "Could not compile the mapping annotations", me );
> throw me;
> }
> }
--
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....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
17 years, 11 months
[Hibernate-JIRA] Commented: (ANN-403) Improve Java 5 Enums dependency on old fashioned enums
by Amir Pashazadeh (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/ANN-403?page=co... ]
Amir Pashazadeh commented on ANN-403:
-------------------------------------
well it makes converting from Java 5 enums to old enums a direct process instead of set of if-else-ifs or a switch case.
I've tested for performance, it was just a small performance improvement, so it can't be the real means for this improvement.
but it will be cleaner code, a accessor instead of a list of if-else-ifs.
> Improve Java 5 Enums dependency on old fashioned enums
> ------------------------------------------------------
>
> Key: ANN-403
> URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-403
> Project: Hibernate Annotations
> Type: Improvement
> Versions: 3.2.0.cr1
> Reporter: Amir Pashazadeh
> Priority: Minor
>
> Original Estimate: 2 hours
> Remaining: 2 hours
>
> Converting from new enum types (like FlushModeType and CacheModeType) to old enum types (which is used by Query, Critiera, and ... interfaces) is not done well, and well formed.
> By adding constructors to new enums this could be much better, and more perform!
> I will attach what must have been done in FlushModeType, the same thing must happen to CacheModeType:
> public enum FlushModeType {
> /**
> * see {@link org.hibernate.FlushMode.ALWAYS}
> */
> ALWAYS(FlushMode.ALWAYS),
> /**
> * see {@link org.hibernate.FlushMode.AUTO}
> */
> AUTO(FlushMode.AUTO),
> /**
> * see {@link org.hibernate.FlushMode.COMMIT}
> */
> COMMIT(FlushMode.COMMIT),
> /**
> * see {@link org.hibernate.FlushMode.NEVER}
> */
> NEVER(FlushMode.NEVER);
> FlushModeType(FlushMode flushMode) {
> this.flushMode = flushMode;
> }
> private FlushMode flushMode;
> /**
> * @return old type proper FlushMode
> */
> public FlushMode getFlushMode() {
> return flushMode;
> }
> }
--
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....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
17 years, 11 months