[Hibernate-JIRA] Created: (ANN-469) bulk update with native sql queries
by Amir Pashazadeh (JIRA)
bulk update with native sql queries
-----------------------------------
Key: ANN-469
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-469
Project: Hibernate Annotations
Type: Improvement
Components: binder
Versions: 3.2.0.ga
Reporter: Amir Pashazadeh
Priority: Critical
Hibernate Annotations 3.2 does not support bulk update/deletes using native queries,
if I have something like:
@NamedNativeQuery(name = "testQuery", query = "delete from tb_test where id = ?")
in one of my entities, there will be following exception during build of SessionFactory :
Exception in thread "main" org.hibernate.cfg.NotYetImplementedException: Pure native scalar queries are not yet supported
at org.hibernate.cfg.annotations.QueryBinder.bindNativeQuery(QueryBinder.java:118)
at org.hibernate.cfg.annotations.QueryBinder.bindNativeQueries(QueryBinder.java:197)
at org.hibernate.cfg.AnnotationBinder.bindQueries(AnnotationBinder.java:281)
at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:404)
at org.hibernate.cfg.AnnotationConfiguration.processArtifactsOfType(AnnotationConfiguration.java:452)
at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:268)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1210)
------
I made a mistake and I reported this issue as HHH-2147 as an issue about Hibernate core! :(
--
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
11 years, 9 months
[Hibernate-JIRA] Created: (HHH-5855) The method "merge" from the EntityManager causes a duplicated "insert" of a child entity.
by Seth Martin (JIRA)
The method "merge" from the EntityManager causes a duplicated "insert" of a child entity.
-----------------------------------------------------------------------------------------
Key: HHH-5855
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5855
Project: Hibernate Core
Issue Type: Bug
Components: annotations, core, entity-manager
Affects Versions: 3.6.0, 3.3.1
Environment: Hibernate-Core 3.6.0, Hibernate EntityManager 3.6.0, Derby, Spring 3.0.5 (Configuration), JUnit 4.5
Reporter: Seth Martin
Priority: Critical
Attachments: CascadeMergeTest.zip
The method "merge" from the EntityManager causes a duplicated "insert" of a child entity.
Related to HHH-3332
h3.Observed Behavior:
When you have an Entity A with a OneToMany(fetch=LAZY, cascade=ALL or (MERGE and PERSIST)) relationship to another Entity B and attempt to add an new B instance to A hibernate will generate a duplicate insert command upon commit.
I have witnessed this problem occurring when this procedure is followed:
# retrieve an instance of A from persistence (A a = em.find(A.class, id))
# add a new B to A (a.getBs.add(new B()))
# merge instance 'a' back into persistence (em.merge(a))
Upon transaction commit hibernate will generate an additional "insert" statement and insert the new instance of b into the data source twice.
h3.Expected behavior:
I would expect hibernate to only perform a single insertion when 'a' is merged back to persistence and the B's are created through the cascade.
h3.Notes (Discoveries):
This problem can be worked around by:
* Changing the OneToMany relationship from a List to a Set
* Only using either Cascade MERGE or PERSIST not both of ALL
* Add a new B to A.getBs by adding to the '0' index (a.getBs.add(0,new B()))
--
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
11 years, 9 months
[Hibernate-JIRA] Created: (HHH-2171) Transaction Rollback Problem in GA due to jboss cache alpha dependency
by bhumika thakkar (JIRA)
Transaction Rollback Problem in GA due to jboss cache alpha dependency
----------------------------------------------------------------------
Key: HHH-2171
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2171
Project: Hibernate3
Type: Bug
Components: build
Versions: 3.2.0.ga
Reporter: bhumika thakkar
We upgraded to Hibernate GA, and started getting Transaction Rolloback Exception. GA release is distributed with JBoss cache alpha quality dependency. Upgrading to the current production release of it fixes the issue.
Stack trace:
org.jboss.cache.interceptors.TxInterceptor.runRollbackPhase Rollback had
a problem
java.lang.IllegalStateException: local transaction Transaction[]
transaction does not match running tx null
at
org.jboss.cache.interceptors.TxInterceptor.handleCommitRollback(TxInterc
eptor.java:616)
at
org.jboss.cache.interceptors.TxInterceptor.runRollbackPhase(TxIntercepto
r.java:696)
at
org.jboss.cache.interceptors.TxInterceptor$RemoteSynchronizationHandler.
afterCompletion(TxInterceptor.java:947)
at
org.jboss.cache.interceptors.OrderedSynchronizationHandler.afterCompleti
on(OrderedSynchronizationHandler.java:80)
at
com.caucho.transaction.TransactionImpl.callAfterCompletion(TransactionIm
pl.java:893)
at
com.caucho.transaction.TransactionImpl.commit(TransactionImpl.java:713)
at
com.caucho.transaction.TransactionManagerImpl.commit(TransactionManagerI
mpl.java:263)
at
com.caucho.jca.UserTransactionImpl.commit(UserTransactionImpl.java:411)
at
com.caucho.jca.UserTransactionProxy.commit(UserTransactionProxy.java:142
)
at
org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTr
ansactionManager.java:787)
at
org.springframework.transaction.support.AbstractPlatformTransactionManag
er.processCommit(AbstractPlatformTransactionManager.java:500)
at
org.springframework.transaction.support.AbstractPlatformTransactionManag
er.commit(AbstractPlatformTransactionManager.java:473)
at
org.springframework.transaction.interceptor.TransactionAspectSupport.doC
ommitTransactionAfterReturning(TransactionAspectSupport.java:267)
at
org.springframework.transaction.interceptor.TransactionInterceptor.invok
e(TransactionInterceptor.java:106)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Ref
lectiveMethodInvocation.java:170)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAo
pProxy.java:176)
at $Proxy119.executeCallback(Unknown Source)
...
--
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
11 years, 10 months
[Hibernate-JIRA] Created: (HHH-3235) Re-assembling entity from clustered JBoss Cache may fail with "argument type mismatch"
by Peter Johnson (JIRA)
Re-assembling entity from clustered JBoss Cache may fail with "argument type mismatch"
--------------------------------------------------------------------------------------
Key: HHH-3235
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3235
Project: Hibernate3
Issue Type: Bug
Affects Versions: 3.2.4.sp1
Environment: 3.2.4.sp1 in JBoss 4.2.2 GA, with MySQL 5.0.32 ( JBoss log also reports Hibernate EntityManager 3.2.1.GA, Hibernate Annotations 3.2.1.GA )
Reporter: Peter Johnson
My application is configured for Hibernate to use the JBoss Cache TreeCache and I have the application deployed in a JBoss cluster. For some reason, with the latest deployment of my software (probably coincidentally when I moved to JBoss Seam 2.0) I started running into a problem where I would get an IllegalArgumentException when Hibernate pulled entities out of the replicated instance of the cache.
It looks like when Hibernate pulls values out of the cache and attempts to re-assemble an entity from a CacheEntry, it tries to put a value into the wrong property of the entity. My entity has several int fields and a single String field. The full stack trace is at the end of this description.
Looking briefly at the source for CacheEntry, it appears to store the entity's property values in an array, and when it later obtains the list of properties (from entity metadata) in order to re-assemble the entity, it assumes the order will match the order of the value array in the CacheEntry. So in my case, either the property values must be in a different order in the second JVM's cache instance, or the list of properties in the entity metadata must be different.
Looking at the printDetails of the EJB3EntityTreeCache MBean in both JBoss instances, the CacheEntries seem to have the values in the same order--at least it prints the values in the same order on each instance. This leads me to believe that the entity metadata identifies the properties in a different order in the two JVMs. (I don't have definitive proof, however).
Setting hibernate.cache.use_structured_entries to "true" works around the problem.
2008-04-07 14:52:07,590 ERROR [org.hibernate.property.BasicPropertyAccessor] IllegalArgumentException in class: com.zattoo.channelserver.entity.permission.AbstractPermissionRule, setter method of property: rule
2008-04-07 14:52:07,590 ERROR [org.hibernate.property.BasicPropertyAccessor] expected type: java.lang.String, actual value: java.lang.Integer
2008-04-07 14:52:07,591 INFO [org.hibernate.event.def.DefaultLoadEventListener] Error performing load command
org.hibernate.PropertyAccessException: IllegalArgumentException occurred while calling setter of com.zattoo.channelserver.entity.permission.AbstractPermissionRule.rule
at org.hibernate.property.BasicPropertyAccessor$BasicSetter.set(BasicPropertyAccessor.java:104)
at org.hibernate.tuple.entity.AbstractEntityTuplizer.setPropertyValues(AbstractEntityTuplizer.java:337)
at org.hibernate.tuple.entity.PojoEntityTuplizer.setPropertyValues(PojoEntityTuplizer.java:200)
at org.hibernate.persister.entity.AbstractEntityPersister.setPropertyValues(AbstractEntityPersister.java:3566)
at org.hibernate.cache.entry.CacheEntry.assemble(CacheEntry.java:116)
at org.hibernate.cache.entry.CacheEntry.assemble(CacheEntry.java:82)
at org.hibernate.event.def.DefaultLoadEventListener.assembleCacheEntry(DefaultLoadEventListener.java:553)
at org.hibernate.event.def.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:508)
at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:357)
at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:139)
at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:195)
at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:103)
at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:878)
at org.hibernate.impl.SessionImpl.internalLoad(SessionImpl.java:846)
at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:557)
at org.hibernate.type.ManyToOneType.assemble(ManyToOneType.java:196)
at org.hibernate.collection.PersistentBag.initializeFromCache(PersistentBag.java:141)
at org.hibernate.cache.entry.CollectionCacheEntry.assemble(CollectionCacheEntry.java:35)
at org.hibernate.event.def.DefaultInitializeCollectionEventListener.initializeCollectionFromCache(DefaultInitializeCollectionEventListener.java:130)
at org.hibernate.event.def.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeCollectionEventListener.java:48)
at org.hibernate.impl.SessionImpl.initializeCollection(SessionImpl.java:1716)
at org.hibernate.collection.AbstractPersistentCollection.forceInitialization(AbstractPersistentCollection.java:454)
at org.hibernate.engine.StatefulPersistenceContext.initializeNonLazyCollections(StatefulPersistenceContext.java:797)
at org.hibernate.event.def.DefaultLoadEventListener.assembleCacheEntry(DefaultLoadEventListener.java:580)
at org.hibernate.event.def.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:508)
at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:357)
at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:139)
at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:195)
at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:103)
at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:878)
at org.hibernate.impl.SessionImpl.internalLoad(SessionImpl.java:846)
at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:557)
at org.hibernate.type.ManyToOneType.assemble(ManyToOneType.java:196)
at org.hibernate.collection.PersistentBag.initializeFromCache(PersistentBag.java:141)
at org.hibernate.cache.entry.CollectionCacheEntry.assemble(CollectionCacheEntry.java:35)
at org.hibernate.event.def.DefaultInitializeCollectionEventListener.initializeCollectionFromCache(DefaultInitializeCollectionEventListener.java:130)
at org.hibernate.event.def.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeCollectionEventListener.java:48)
at org.hibernate.impl.SessionImpl.initializeCollection(SessionImpl.java:1716)
at org.hibernate.collection.AbstractPersistentCollection.forceInitialization(AbstractPersistentCollection.java:454)
at org.hibernate.Hibernate.initialize(Hibernate.java:309)
at com.zattoo.channelserver.session.ChannelProviderBean.getAllPartitions(ChannelProviderBean.java:127)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166)
at org.jboss.seam.intercept.EJBInvocationContext.proceed(EJBInvocationContext.java:44)
at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:101)
at org.jboss.seam.intercept.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:50)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:118)
at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:95)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77)
at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:110)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessContainer.localInvoke(StatelessContainer.java:240)
at org.jboss.ejb3.stateless.StatelessContainer.localInvoke(StatelessContainer.java:210)
at org.jboss.ejb3.stateless.StatelessLocalProxy.invoke(StatelessLocalProxy.java:84)
at $Proxy161.getAllPartitions(Unknown Source)
at com.zattoo.channelserver.service.ChannelCacheService.loadPartitionCache(ChannelCacheService.java:136)
at com.zattoo.channelserver.service.ChannelCacheService.getAllPartitions(ChannelCacheService.java:155)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166)
at org.jboss.seam.intercept.EJBInvocationContext.proceed(EJBInvocationContext.java:44)
at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:101)
at org.jboss.seam.intercept.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:50)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:118)
at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:191)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:95)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77)
at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:110)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.service.ServiceContainer.localInvoke(ServiceContainer.java:329)
at org.jboss.ejb3.service.ServiceContainer.localInvoke(ServiceContainer.java:294)
at org.jboss.ejb3.service.ServiceMBeanDelegate.getAttribute(ServiceMBeanDelegate.java:139)
at org.jboss.mx.server.RawDynamicInvoker.getAttribute(RawDynamicInvoker.java:117)
at org.jboss.mx.server.MBeanServerImpl.getAttribute(MBeanServerImpl.java:556)
at org.jboss.jmx.adaptor.control.Server.getMBeanAttributeResultInfo(Server.java:144)
at org.apache.jsp.inspectMBean_jsp._jspService(inspectMBean_jsp.java:185)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:373)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:336)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:265)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:654)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:445)
at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:379)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:292)
at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.inspectMBean(HtmlAdaptorServlet.java:204)
at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:96)
at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doGet(HtmlAdaptorServlet.java:77)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:856)
at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:566)
at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1508)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.IllegalArgumentException: argument type mismatch
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.hibernate.property.BasicPropertyAccessor$BasicSetter.set(BasicPropertyAccessor.java:42)
... 155 more
--
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
11 years, 10 months
[Hibernate-JIRA] Created: (EJB-376) EntityManager.createQuery does not recognize COUNT CASE statement
by Mark Plutowski (JIRA)
EntityManager.createQuery does not recognize COUNT CASE statement
-----------------------------------------------------------------
Key: EJB-376
URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-376
Project: Hibernate Entity Manager
Issue Type: Bug
Components: EntityManager
Affects Versions: 3.4.0.CR2, 3.3.1.GA
Environment: Tested with both Hibernate 3.2.5.ga and Hibernate 3.3.0.CR2, Postgres 8.1, Postgres 8.2, Linux Ubuntu.
Reporter: Mark Plutowski
I searched the Hibernate forums and did not find mention of this issue or one that was closely related. I also posted this to the Hibernate Users forum, and did not receive any replies recognizing the bug or stating that it has been resolved or has a workaround.
To summarize, EntityManager.createQuery does not recognize SQL related to applying a COUNT to a CASE, whereas it does correctly run SQL that applies a SUM to a CASE. More detail follows.
--- Summary Overview ---
EntityManager.createQuery runs a SELECT query containing the following HQL/JQL snippet runs correctly:
" SUM ( CASE WHEN (cs.serveTs BETWEEN :beginTs AND :endTs ) THEN 1 ELSE 0 END ) "
However, the following do not work:
" COUNT ( DISTINCT CASE WHEN (cs.serveTs BETWEEN :beginTs AND :endTs ) THEN cs.componentId ELSE NULL END ) "
" COUNT ( DISTINCT (CASE WHEN (cs.serveTs BETWEEN :beginTs AND :endTs ) THEN cs.componentId ELSE NULL END ) ) "
" COUNT ( CASE WHEN (cs.serveTs BETWEEN :beginTs AND :endTs ) THEN cs.componentId ELSE NULL END ) "
The first two statements run and return correct results when translated to SQL and run against the Postgresql database in PgAdmin.
Here's the exception thrown when using COUNT ( DISTINCT CASE WHEN
101976 [main] ERROR org.hibernate.hql.PARSER - line 1:93: unexpected token: CASE
101977 [main] ERROR org.hibernate.hql.PARSER - line 1:98: unexpected token: WHEN
Here's the exception thrown when the extra parenthesis is added to give COUNT ( DISTINCT (CASE WHEN
85587 [main] ERROR org.hibernate.hql.PARSER - line 1:93: unexpected token: (
85588 [main] ERROR org.hibernate.hql.PARSER - line 1:99: unexpected token: WHEN
--- Additional Detail ---
Here is the complete SQL for the COUNT (DISTINCT (CASE use case:
String queryString = "Select c.id.pubId, c.id.clipId, c.duration, " +
"count(distinct s.slotId) , " +
" COUNT ( DISTINCT (CASE WHEN (cs.serveTs BETWEEN :beginTs AND :endTs ) THEN cs.componentId ELSE NULL END ) ) " +
"from CmClip c " +
"join c.cmClipSlots s " +
"left outer join c.csComponents cs " +
"where (s.adSizeX * c.width) >= :adWidth " +
"and (s.adSizeY * c.height) >= :adHeight " +
"and (c.isQaDone = true or c.isQaDone is null) " +
"and c.isEnabled = true " +
"group by c.id.pubId, c.id.clipId, c.duration " +
"order by " + orderByCol;
This results in the following exception:
85587 [main] ERROR org.hibernate.hql.PARSER - line 1:93: unexpected token: (
85588 [main] ERROR org.hibernate.hql.PARSER - line 1:99: unexpected token: WHEN
Here is the SQL for the SUM CASE sql snippet that does run and return correct results:
String queryString = "Select c.id.pubId, c.id.clipId, c.duration, " +
"count(distinct s.slotId) , " +
" SUM ( CASE WHEN (cs.serveTs BETWEEN :beginTs AND :endTs ) THEN 1 ELSE 0 END ) " +
"from CmClip c " +
"join c.cmClipSlots s " +
"left outer join c.csComponents cs " +
"where (s.adSizeX * c.width) >= :adWidth " +
"and (s.adSizeY * c.height) >= :adHeight " +
"and (c.isQaDone = true or c.isQaDone is null) " +
"and c.isEnabled = true " +
"group by c.id.pubId, c.id.clipId, c.duration " +
"order by " + orderByCol;
Here is the code snippet that performs the transaction:
float roFactor = (float) 0.5;
transactionMgr.begin();
List<Object[]> result = entityMgr.createQuery(queryString)
.setParameter("adWidth", (widthF-roFactor)).
setParameter("adHeight", (heightF-roFactor))
.setParameter("beginTs", beginTs, javax.persistence.TemporalType.TIMESTAMP)
.setParameter("endTs", endTs, javax.persistence.TemporalType.TIMESTAMP)
.getResultList();
transactionMgr.commit();
The fact that "SUM (CASE" is parsed and run correctly, whereas "COUNT (CASE" throws an exception seems to indicate a bug. I replicated this using both (Hibernate 3.2.5.ga with EntityManager 3.3.1.GA) and (Hibernate 3.3.0.CR2 with EntityManager 3.4.0.CR2).
--
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
11 years, 10 months
[Hibernate-JIRA] Created: (HHH-4084) @UniqueConstraint(columnNames="") causes StringIndexOutOfBoundsException
by Ondra Žižka (JIRA)
@UniqueConstraint(columnNames="") causes StringIndexOutOfBoundsException
------------------------------------------------------------------------
Key: HHH-4084
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4084
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.0.GA
Reporter: Ondra Žižka
Priority: Trivial
Empty string in columnNames attribute causes StringIndexOutOfBoundsException:
@Entity
@Table( name="items", uniqueConstraints=@UniqueConstraint(columnNames="") )
public class Item implements Serializable { ... }
---------------
Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: 0
at java.lang.String.charAt(String.java:686)
at org.hibernate.mapping.Column.setName(Column.java:84)
at org.hibernate.mapping.Column.<init>(Column.java:65)
at org.hibernate.cfg.AnnotationConfiguration.buildUniqueKeyFromColumnNames(AnnotationConfiguration.java:591)
at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:348)
at org.hibernate.cfg.Configuration.buildMappings(Configuration.java:1148)
at org.hibernate.ejb.Ejb3Configuration.buildMappings(Ejb3Configuration.java:1226)
at org.hibernate.ejb.EventListenerConfigurator.configure(EventListenerConfigurator.java:173)
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:854)
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:425)
at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:131)
--
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
11 years, 10 months
[Hibernate-JIRA] Created: (HHH-5845) Lazy Loading of audited entites with revision type 'delete'
by Jonas Schlaak (JIRA)
Lazy Loading of audited entites with revision type 'delete'
-----------------------------------------------------------
Key: HHH-5845
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5845
Project: Hibernate Core
Issue Type: Bug
Components: envers
Affects Versions: 3.5.6
Environment: Hibernate 3.5.6, Oracle 10 DB
Reporter: Jonas Schlaak
Two classes are given, and they are related via a OneToOne relationship:
@Audited
public class MyClass {
@OneToOne
@Cascade(value = CascadeType.ALL)
private MyOtherClass otherClass;
}
@Audited
public class MyOtherClass {
}
The property "org.hibernate.envers.store_data_at_delete" is set to true, and when auditquerying for the deleted objects and initiliazing the otherClass (an entity which is also deleted) property, and ObjectNotFoundExceptions is thrown. It seems that the proxies do not look for deleted entities, because the same query works fine for the entities of revision type 'ADD' and 'MOD'. The code of the query:
AuditQuery queryDeleted = reader.createQuery().forRevisionsOfEntity(
MyClass.class, false, true).add(
AuditEntity.revisionType().eq(RevisionType.DEL));
List queryResult = queryDeleted.getResultList();
List<MyClass> result = new ArrayList<MyClass>();
for (Object object : queryResult) {
Object[] oArray = (Object[]) object;
MyClass c = (MyClass) oArray[0];
Hibernate.initialize(c.getOtherClass());
}
Forum post with Adam Warski's response:
http://community.jboss.org/thread/160939?tstart=0
--
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
11 years, 10 months