[Hibernate-JIRA] Commented: (HHH-1468) No Dialect mapping for JDBC type: 3 Exception
by Brian Viveiros (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1468?page=c... ]
Brian Viveiros commented on HHH-1468:
-------------------------------------
I'm having the same problem when running a createSQLQuery("select count(some_id) from some_table'). The some_id column is an Int.
MySQL 5.0
MySQL Connector 3.1.11
> No Dialect mapping for JDBC type: 3 Exception
> ---------------------------------------------
>
> Key: HHH-1468
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1468
> Project: Hibernate3
> Type: Bug
> Reporter: Bhumika Thakkar
>
>
> I get an exception when the following native query returns a decimal type.
>
> sample code
> @SqlResultSetMapping(name = "scalar", columns = @ColumnResult(name = "amount"))
> @NamedNativeQuery(name = "getAmount", query = "select sum(amount) as amount from billing where id=1", resultSetMapping = "scalar")
> $RCSfile: ExceptionHandler.java,v $.execute Exception
> org.hibernate.MappingException: No Dialect mapping for JDBC type: 3
> at org.hibernate.dialect.TypeNames.get(TypeNames.java:56)
> at org.hibernate.dialect.TypeNames.get(TypeNames.java:81)
> at org.hibernate.dialect.Dialect.getHibernateTypeName(Dialect.java:192)
> at org.hibernate.loader.custom.CustomLoader.getHibernateType(CustomLoader.jav
> a:170)
> at org.hibernate.loader.custom.CustomLoader.autoDiscoverTypes(CustomLoader.ja
> va:152)
> at org.hibernate.loader.Loader.getResultSet(Loader.java:1678)
> at org.hibernate.loader.Loader.doQuery(Loader.java:662)
> at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.
> java:224)
> at org.hibernate.loader.Loader.doList(Loader.java:2150)
> at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2029)
> at org.hibernate.loader.Loader.list(Loader.java:2024)
> at org.hibernate.loader.custom.CustomLoader.list(CustomLoader.java:117)
> at org.hibernate.impl.SessionImpl.listCustomQuery(SessionImpl.java:1672)
> at org.hibernate.impl.AbstractSessionImpl.list(AbstractSessionImpl.java:147)
> at org.hibernate.impl.SQLQueryImpl.list(SQLQueryImpl.java:169)
> at org.springframework.orm.hibernate3.HibernateTemplate$33.doInHibernate(Hibe
> rnateTemplate.java:920)
> at org.springframework.orm.hibernate3.HibernateTemplate.execute(HibernateTemp
> late.java:365)
> at org.springframework.orm.hibernate3.HibernateTemplate.findByNamedQueryAndNa
> medParam(HibernateTemplate.java:911)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
> 39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorIm
> pl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(Ao
> pUtils.java:335)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoi
> nt(ReflectiveMethodInvocation.java:181)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Refle
> ctiveMethodInvocation.java:148)
> at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(
> TransactionInterceptor.java:96)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Refle
> ctiveMethodInvocation.java:170)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopP
> roxy.java:176)
> at $Proxy76.getTotalLeadPayout(Unknown Source)
> at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProc
> essor.java:419)
> at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:22
> 4)
> at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
> at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:115)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:92)
> at com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.
> java:99)
> at com.caucho.server.security.SecurityFilterChain.doFilter(SecurityFilterChai
> n.java:135)
> at com.caucho.server.cache.CacheFilterChain.doFilter(CacheFilterChain.java:20
> 9)
> at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java
> :163)
> at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.jav
> a:208)
> at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:259)
> at com.caucho.server.port.TcpConnection.run(TcpConnection.java:363)
> at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:490)
> at com.caucho.util.ThreadPool.run(ThreadPool.java:423)
> at java.lang.Thread.run(Thread.java:595)
> $RCSfile: ExceptionHandler.java,v $.execute Exception Cause 1
> org.hibernate.MappingException: No Dialect mapping for JDBC type: 3
> at org.hibernate.dialect.TypeNames.get(TypeNames.java:56)
> at org.hibernate.dialect.TypeNames.get(TypeNames.java:81)
> at org.hibernate.dialect.Dialect.getHibernateTypeName(Dialect.java:192)
> at org.hibernate.loader.custom.CustomLoader.getHibernateType(CustomLoader.jav
> a:170)
> at org.hibernate.loader.custom.CustomLoader.autoDiscoverTypes(CustomLoader.ja
> va:152)
> at org.hibernate.loader.Loader.getResultSet(Loader.java:1678)
> at org.hibernate.loader.Loader.doQuery(Loader.java:662)
> at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.
> java:224)
> at org.hibernate.loader.Loader.doList(Loader.java:2150)
> at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2029)
> at org.hibernate.loader.Loader.list(Loader.java:2024)
> at org.hibernate.loader.custom.CustomLoader.list(CustomLoader.java:117)
> at org.hibernate.impl.SessionImpl.listCustomQuery(SessionImpl.java:1672)
> at org.hibernate.impl.AbstractSessionImpl.list(AbstractSessionImpl.java:147)
> at org.hibernate.impl.SQLQueryImpl.list(SQLQueryImpl.java:169)
> at org.springframework.orm.hibernate3.HibernateTemplate$33.doInHibernate(Hibe
> rnateTemplate.java:920)
> at org.springframework.orm.hibernate3.HibernateTemplate.execute(HibernateTemp
> late.java:365)
> at org.springframework.orm.hibernate3.HibernateTemplate.findByNamedQueryAndNa
> medParam(HibernateTemplate.java:911)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
> 39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorIm
> pl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(Ao
> pUtils.java:335)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoi
> nt(ReflectiveMethodInvocation.java:181)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Refle
> ctiveMethodInvocation.java:148)
> at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(
> TransactionInterceptor.java:96)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Refle
> ctiveMethodInvocation.java:170)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopP
> roxy.java:176)
> at $Proxy76.getTotalLeadPayout(Unknown Source)
> at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProc
> essor.java:419)
> at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:22
> 4)
> at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
> at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:115)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:92)
> at com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.
> java:99)
> at com.caucho.server.security.SecurityFilterChain.doFilter(SecurityFilterChai
> n.java:135)
> at com.caucho.server.cache.CacheFilterChain.doFilter(CacheFilterChain.java:20
> 9)
> at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java
> :163)
> at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.jav
> a:208)
> at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:259)
> at com.caucho.server.port.TcpConnection.run(TcpConnection.java:363)
> at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:490)
> at com.caucho.util.ThreadPool.run(ThreadPool.java:423)
> at java.lang.Thread.run(Thread.java:595)
--
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, 8 months
[Hibernate-JIRA] Commented: (HHH-1907) make ComponentType operate more like EntityType
by Josh Moore (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1907?page=c... ]
Josh Moore commented on HHH-1907:
---------------------------------
Steve, would this make it possible to get to more of the ComponentMetamodel?
Noticed this in ComponentType:
public ComponentType(ComponentMetamodel metamodel) {
// for now, just "re-flatten" the metamodel since this is temporary stuff anyway (HHH-1907)
What I find to be missing is access to the updatability/insertablity/etc. of the EmbeddedComponent properties.
> make ComponentType operate more like EntityType
> -----------------------------------------------
>
> Key: HHH-1907
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1907
> Project: Hibernate3
> Type: Improvement
> Components: core
> Reporter: Steve Ebersole
> Assignee: Steve Ebersole
>
>
> Specifically, we need to move all the code directly dealing with property-access, instantiation, etc out of here. So where do we move it? Well, EntityType for example moves this stuff off to the persisters; the type then just looks up the persister when needed. Not sure we actually need a persister per-se for handling components; perhaps just ComponentMetamodel is enough...
> Why is this important? Well the way ComponentType is currently structured leads to the need for certain configuration properties to be classloader scoped (static on Environment) instead of SessionFactory scoped. This is painful for two in particular: 1) whether to use reflection optimization and 2) bytecode provider.
> Also, this change should allow us to cleanup how property accessors are built
--
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, 8 months
[Hibernate-JIRA] Commented: (HBX-484) Generated DAOs and POJO only work with JDK5 when using bigint or smallint as ID
by Matt Wendling (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-484?page=co... ]
Matt Wendling commented on HBX-484:
-----------------------------------
I'm seeing a similar problem with MySql 5 and DAO generation with Tools 3.2 beta7:
public Survey findById(int id) {
log.debug("getting Survey instance with id: " + id);
try {
Survey instance = (Survey) sessionFactory.getCurrentSession().get( "rhi.survey.Survey", id);
> Generated DAOs and POJO only work with JDK5 when using bigint or smallint as ID
> -------------------------------------------------------------------------------
>
> Key: HBX-484
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-484
> Project: Hibernate Tools
> Type: Bug
> Components: reverse-engineer
> Versions: 3.1beta1
> Environment: hibernate 3.05
> hsql 1.7.1 or postgres 7.4.7
> Reporter: Heinz Stüßer
> Attachments: daohome.vm.patch, testcase.zip
>
>
> Using the eclipse-plugin I generated POJOs and DAOS for the tables created with the script create.sql.
> 1st)
> The generated DAOs contain code (in the method findById) when using smallint or bigint as primary key which only works fine with JDK5. Using int as primary key produces correct code for all JDKs. Smallint or bigint are converted in the POJOs and the DAOs to the primitive java-datatypes small resp. long, while int is converted to the an object of type Integer.
> The attached testcase.zip contains a createscript for 3 tiny tables and the generated DAOs and POJOs.
> 2nd)
> daohome.vm contains code which results in a static import anytime. The attached daohome.vm.patch contains a patch to fix this problem.
--
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, 8 months
[Hibernate-JIRA] Commented: (EJB-46) Property Validation should happen after PrePersist/PreUpdate
by Mark Menard (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/EJB-46?page=com... ]
Mark Menard commented on EJB-46:
--------------------------------
Hi Emmanuel,
This patch fixes the following scenario. Create an entity with new (). Do not set the primary key. Call EntityManager.persist() on the new entity with a null primary key. The entity has a method marked with @PrePersist to set the primary key on the entity, but Hibernate checks the primary key before executing the @PrePersist method. Thus it throws an exception like the following:
Caused by: org.hibernate.id.IdentifierGenerationException: ids for this class must be manually assigned before calling save():
16:28:15,411 INFO [STDOUT] net.vitarara.quadran.core.data.jpa.PartyJpaImpl
at org.hibernate.id.Assigned.generate(Assigned.java:33)
at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:98)
at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:131)
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:87)
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:38)
at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:618)
at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:592)
at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:596)
at org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:212)
If you could give me pointers on how to create a test scenario that would illustrate this I'd be happy to try, but I'll admit I'm a complete Hibernate novice. The only experience I have with Hibernate was downloading Michal's patch, and applying it by hand to 3.2.0.RC2, building, and using the jars thus created.
> 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....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
17 years, 8 months
[Hibernate-JIRA] Commented: (EJB-46) Property Validation should happen after PrePersist/PreUpdate
by Emmanuel Bernard (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/EJB-46?page=com... ]
Emmanuel Bernard commented on EJB-46:
-------------------------------------
Hi,
I don't understand what this patch fixes.
This is not the PropertyValueException because the test is done after invokeSaveLifecycle for what I can tell.
Can somebody add a test case failing before the patch and working after it?
> 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....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
17 years, 8 months
[Hibernate-JIRA] Commented: (HHH-1621) subclass mapping by discriminator - should instantiate parent for unmapped discriminator values
by Felipe Zschornack (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1621?page=c... ]
Felipe Zschornack commented on HHH-1621:
----------------------------------------
I have the same problem. The select clause generated by Hibernate not consider the discriminator column (this column is not part of the 'where' part of the select).
When Hibernate try to get the discriminator value, a erroneous key is used (in my case, instead of discriminator key, the primary key was used), so
so the 'get' method of the subclassesByDiscriminatorValue HashMap
subclassesByDiscriminatorValue.get(value); (SingleTableEntityPersister.java:431)
will return 'null' instead of the correct discriminator value. This occurs in
final String result = persister.getSubclassForDiscriminatorValue( discriminatorValue ); (Loader.java:1441)
> subclass mapping by discriminator - should instantiate parent for unmapped discriminator values
> -----------------------------------------------------------------------------------------------
>
> Key: HHH-1621
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1621
> Project: Hibernate3
> Type: Improvement
> Components: core
> Environment: 3.1.2
> Sybase ASE 12.5.3
> Reporter: Martin Schulz
> Attachments: HHH-1621
>
>
> Scenario: The parent class A has a discriminator field and some but all possible scriminator values are mapped to subclasses.
> Current behavior:
> 1) Default:
> The following exception is thrown
> org.hibernate.WrongClassException: Object with id: 10000 was not of the specified subclass: A (Discriminator: D)
> at org.hibernate.loader.Loader.getInstanceClass(Loader.java:1445)
> [ the error itself is also quite misleading, as the row is exactly of / for the specified class A. But there simply was no
> subclass found ].
> 2) discriminator with force="true"
> The parent class is never instantiated, only the mapped subclasses are instantiated.
> Proposed behavior:
> The parent class should be instantiated for those rows with unmapped discriminator values.
> Characteristics of proposed behavior:
> - all rows in resultset would lead to instantiated class in the inheritence tree,
> - the behavior would be in line with how joined-subclass behaves
> - no caveat documentation required
> Implementation:
> (Easy)
> in Loader.java, lines 1443ff, do not throw WrongClassException, but instead
> return persister.getEntityName();
> (Alternate)
> change persister.getSubclassForDiscriminatorValue() implementations correspondingly.
> Thx for your consideration / vote.
--
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, 8 months
[Hibernate-JIRA] Commented: (EJB-46) Property Validation should happen after PrePersist/PreUpdate
by Mark Menard (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/EJB-46?page=com... ]
Mark Menard commented on EJB-46:
--------------------------------
Correction to my note on the patch. This is done against hibernate-eventmanager-3.2.0.CR2.
> 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....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
17 years, 8 months