[Hibernate-JIRA] Created: (HHH-2381) Criteria API : Order by Native SQL
by Sami Dalouche (JIRA)
Criteria API : Order by Native SQL
-----------------------------------
Key: HHH-2381
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2381
Project: Hibernate3
Type: Improvement
Components: query-criteria
Reporter: Sami Dalouche
Hi,
It would be nice to be able to specify the ORDER BY clause using Native SQL. (It is currently doable by subclassing the Order class, but some nice solution would allow the order to specify attributes on another table..)
Let's take a simple example : I have a distance("attribute", geometry) function, that is of course, proprietary.
I am quering table A, which I can join to table B to get the "attribute", on which I want to apply my distance() function.
If I create my own Order subclass, and addOrder on the criteria, the distance("attribute, geometry) is going to refer to the main criteria's class mapping.
So, something like addOrder("objectpath.joined", new MyOrder(...)); would be perfect.
What do you think ?
Regards,
Sami Dalouche
--
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
13 years
[Hibernate-JIRA] Created: (HHH-4489) need method "refresh(String entityName, Object obj)"
by Shilin ZHENG (JIRA)
need method "refresh(String entityName, Object obj)"
----------------------------------------------------
Key: HHH-4489
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4489
Project: Hibernate Core
Issue Type: Improvement
Components: core
Affects Versions: 3.3.2
Environment: Idependant
Reporter: Shilin ZHENG
Priority: Blocker
We can save, update, merge etc. an object with "entityName", but not refresh().
Exception is :
FROM-------------------
org.hibernate.MappingException: Unknown entity: com.aca.isie.statparam.fonctional.entities.impl.VariableExp
at org.hibernate.impl.SessionFactoryImpl.getEntityPersister(SessionFactoryImpl.java:548)
at org.hibernate.impl.SessionImpl.getEntityPersister(SessionImpl.java:1338)
at org.hibernate.event.def.DefaultRefreshEventListener.onRefresh(DefaultRefreshEventListener.java:66)
at org.hibernate.event.def.DefaultRefreshEventListener.onRefresh(DefaultRefreshEventListener.java:39)
at org.hibernate.impl.SessionImpl.fireRefresh(SessionImpl.java:902)
at org.hibernate.impl.SessionImpl.refresh(SessionImpl.java:886)
-------------END
When I read line 66 of source file "DefaultRefreshEventListener", I have noticed that you have commented this:
Line 66: persister = source.getEntityPersister(null, object); //refresh() does not pass an entityName
So will you please correct this so that we can pass an "entityName" in "refresh()"? Thank you. In fact, we are on the last phase of our development and we are blocked on this.
--
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
13 years
[Hibernate-JIRA] Created: (HBX-1159) hbm2ddl outputfiles should be comparables
by Maillefer Jean-David (JIRA)
hbm2ddl outputfiles should be comparables
-----------------------------------------
Key: HBX-1159
URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-1159
Project: Hibernate Tools
Issue Type: Improvement
Affects Versions: 3.2.0.GA
Reporter: Maillefer Jean-David
Priority: Minor
It would be very helpful if hbm2ddl could generate comparable output files. By comparable, I mean that using a diff tool, the order of the generated SQL elements should be the same. It's already the case for columns. But it's missing for foreign-keys: each time hbm2ddl is run, their respective order is changed, thus making the use of diff tools nearly useless.
Sample code (for postgresql):
We can see that the order of primary-key fields membre_id and principal_id has changed, but the structure is the same !
Run 1:
create table AdhesionId (
id serial not null,
modification timestamp not null,
version int4,
membre_id int4 not null,
principal_id int4 not null,
primary key (id)
);
Run 2 (after a modification to a field in another class):
create table AdhesionId (
id serial not null,
modification timestamp not null,
version int4,
principal_id int4 not null,
membre_id int4 not null,
primary key (id)
);
--
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
13 years
[Hibernate-JIRA] Created: (HHH-4703) (cglib)Instrumented model with abstract MappedSuperclass and field access doesn't work
by Strong Liu (JIRA)
(cglib)Instrumented model with abstract MappedSuperclass and field access doesn't work
--------------------------------------------------------------------------------------
Key: HHH-4703
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4703
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.5.0-Beta-2, 3.3.2
Reporter: Strong Liu
Notes:
* test runs fine with cglib, hb 3.2.4 SP1 + ann 3.2.1
* test runs fine with cglib, plain mapping files (trunk).
* no matter if you use annotation or mapping files, test will fail using javassist (it used to fail with previous version too)
So focus on instrumentation done using cglib.
See attached testcase to reproduce the problem.
Guideline:
* testcase the pattern used in hb-core, just using annotations
* run org.hibernate.test.instrument2.runtime.CGLIBInstrumentationTest
* easy to switch from annotation to mapping files in org.hibernate.test.instrument2.cases.AbstractExecutable (comment/uncomment specific lines in getAnnotatedClasses and getXmlFiles)
interesting point: if you complete the source with id setters + annotate the getters (instead of fields) + make the getInterestRate @Transient, the test passes.
--
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
13 years
[Hibernate-JIRA] Created: (HBX-1126) cannot start a jbpm proccess because the hibernated generated query, fails with informix 10
by sergio amaya (JIRA)
cannot start a jbpm proccess because the hibernated generated query, fails with informix 10
-------------------------------------------------------------------------------------------
Key: HBX-1126
URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-1126
Project: Hibernate Tools
Issue Type: Bug
Environment: informix 10, hibernate tools Version: 3.2.4
Reporter: sergio amaya
Attachments: datasource-ds.xml, hibernate.cfg.xml
i am working with seam + jbpm (jboss tools) and hibernate is creating this query on the jbpm tables:
the strange thing is that i can run the query and it works, im using informix 10
and if i change the database to postgresql (with another datasource), the hole thing works....
... i think is something about the dialect but im not sure, please help me guys!!
Hibernate generated query:
select first 1 processdef0_.ID_ as ID1_4_, processdef0_.NAME_ as NAME3_4_, processdef0_.DESCRIPTION_ as DESCRIPT4_4_, processdef0_.VERSION_ as VERSION5_4_, processdef0_.ISTERMINATIONIMPLICIT_ as ISTERMIN6_4_, processdef0_.STARTSTATE_ as STARTSTATE7_4_ from JBPM_PROCESSDEFINITION processdef0_ where processdef0_.NAME_=? order by processdef0_.VERSION_ desc
and the error is this
16:39:36,491 INFO [LongType] could not read column value from result set: ID1_4_; No such column name
16:39:36,507 WARN [JDBCExceptionReporter] SQL Error: -79738, SQLState: IX000
16:39:36,507 ERROR [JDBCExceptionReporter] No such column name
the stacktrace
16:39:36,710 ERROR [STDERR] org.hibernate.exception.GenericJDBCException: could not execute query
at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:103)
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
at org.hibernate.loader.Loader.doList(Loader.java:2223)
at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2104)
at org.hibernate.loader.Loader.list(Loader.java:2099)
at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:378)
at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:338)
at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:172)
at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1121)
at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79)
at org.hibernate.impl.AbstractQueryImpl.uniqueResult(AbstractQueryImpl.java:811)
at org.jbpm.db.GraphSession.findLatestProcessDefinition(GraphSession.java:153)
at org.jbpm.JbpmContext.newProcessInstanceForUpdate(JbpmContext.java:417)
at org.jboss.seam.bpm.BusinessProcess.createProcess(BusinessProcess.java:121)
at org.jboss.seam.bpm.BusinessProcessInterceptor.afterInvocation(BusinessProcessInterceptor.java:106)
at org.jboss.seam.bpm.BusinessProcessInterceptor.aroundInvoke(BusinessProcessInterceptor.java:49)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:42)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.persistence.EntityManagerProxyInterceptor.aroundInvoke(EntityManagerProxyInterceptor.java:26)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.persistence.HibernateSessionProxyInterceptor.aroundInvoke(HibernateSessionProxyInterceptor.java:27)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
at org.jboss.seam.intercept.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:50)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
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 $Proxy109.iniciarProceso(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.jboss.seam.util.Reflections.invoke(Reflections.java:21)
at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:31)
at org.jboss.seam.intercept.ClientSideInterceptor$1.proceed(ClientSideInterceptor.java:76)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56)
at org.jboss.seam.security.SecurityInterceptor.aroundInvoke(SecurityInterceptor.java:40)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
at org.jboss.seam.intercept.ClientSideInterceptor.invoke(ClientSideInterceptor.java:54)
at org.javassist.tmp.java.lang.Object_$$_javassist_3.iniciarProceso(Object_$$_javassist_3.java)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:329)
at org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:342)
at org.jboss.el.parser.AstPropertySuffix.invoke(AstPropertySuffix.java:58)
at org.jboss.el.parser.AstValue.invoke(AstValue.java:96)
at org.jboss.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
at com.sun.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:68)
at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:88)
at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102)
at javax.faces.component.UICommand.broadcast(UICommand.java:387)
at org.ajax4jsf.component.AjaxViewRoot.processEvents(AjaxViewRoot.java:184)
at org.ajax4jsf.component.AjaxViewRoot.broadcastEvents(AjaxViewRoot.java:162)
at org.ajax4jsf.component.AjaxViewRoot.processApplication(AjaxViewRoot.java:350)
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:82)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:265)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:85)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:141)
at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.ja
16:39:36,710 ERROR [STDERR] va:281)
at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:60)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.debug.hot.HotDeployFilter.doFilter(HotDeployFilter.java:68)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
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:182)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
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.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
at java.lang.Thread.run(Unknown Source)
Caused by: java.sql.SQLException: No such column name
at com.informix.util.IfxErrMsg.getSQLException(IfxErrMsg.java:348)
at com.informix.jdbc.IfxResultSet.findColumn(IfxResultSet.java:635)
at com.informix.jdbc.IfxResultSet.getLong(IfxResultSet.java:1129)
at org.jboss.resource.adapter.jdbc.WrappedResultSet.getLong(WrappedResultSet.java:724)
at org.hibernate.type.LongType.get(LongType.java:28)
at org.hibernate.type.NullableType.nullSafeGet(NullableType.java:163)
at org.hibernate.type.NullableType.nullSafeGet(NullableType.java:154)
at org.hibernate.loader.Loader.getKeyFromResultSet(Loader.java:1097)
at org.hibernate.loader.Loader.getRowFromResultSet(Loader.java:565)
at org.hibernate.loader.Loader.doQuery(Loader.java:701)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236)
at org.hibernate.loader.Loader.doList(Loader.java:2220)
... 121 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
13 years, 1 month
[Hibernate-JIRA] Created: (HBX-1100) hbm2dll creates FK constraint names that are too large for taget database dialect
by Duncan Keysell (JIRA)
hbm2dll creates FK constraint names that are too large for taget database dialect
---------------------------------------------------------------------------------
Key: HBX-1100
URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-1100
Project: Hibernate Tools
Issue Type: Bug
Affects Versions: 3.2.4 Beta1
Reporter: Duncan Keysell
When hbm2dll creates FK constraint names, it does so without following database resrictions. As hbm2dll knows it is using the Oracle10gDialect then it should not attempt to create FK constraint names that have more than 30 characters. With union-subclass mapping the pattern used by hbm2dll is to give a FK constraint an 18 character name on the class that directly has the association requiring the FK. If that class is subclassed the FK constraint added to the tables of the subclasses has 18+8n characters. Where n is the level of subclassing. Only two levels of subclassing are required before the constraint name exceeds 30 characters as below.
I know it is possible to configure the initial name used for constraints using the foreign-key attribute in the mapping. However if I set that to 1 character then I still have a problem when 1 + 4*8 = 33. Therefore even using the foreign-key attribute I can only get 3 levels of subclassing.
Shouldn't the algorithm to create FK names be aware of the 30 character limit, i.e be dialect aware. Couldn't it simply create a hashcode of the hashcode it currently creates and limit it to 30 characters (including the 'FK').
In the example below constraints of the lengths shown get added to each table for the many-to-one mapping with name="requestedNE":
Class
IACEndpointConfigElement (FK4C10C05A145A4B50) 18 chars
IInterfaceConfigElement (FK4C10C05A145A4B50b6728c4a) 18 + 8 = 26 chars
IFRvcConfigElement (FK4C10C05A145A4B50b6728c4ace4cc838) 18 + 8 + 8 = 34 chars ERROR
Hibernate version:
3.2.2
Mapping documents:
<class name="productSpecific.advancedAppInterfaces.attachmentCircuitService.IACEndpointConfigElement" table="IACEndpointConfigElement" abstract="true">
<many-to-one name="requestedNE"
class="productSpecific.advancedAppInterfaces.attachmentCircuitService.IACServiceNEAssignmentConfigElement"
column="requestedNE_ID"
foreign-key="none"
not-found="ignore"
/>
<union-subclass name="productSpecific.advancedAppInterfaces.attachmentCircuitService.IInterfaceConfigElement" table="IInterfaceConfigElement" abstract="false">
<union-subclass name="productSpecific.advancedAppInterfaces.attachmentCircuitService.IFRvcConfigElement" table="IFRvcConfigElement" abstract="false">
</union-subclass>
</union-subclass>
</class
Code between sessionFactory.openSession() and session.close():
N/A
Full stack trace of any exception that occurs:
N/A
Name and version of the database you are using:
Oracle 10g
The generated SQL (show_sql=true):
[hibernatetool] 2008-11-26 09:56:40,000 DEBUG SchemaExport:303 -
[hibernatetool] create table developer.IFRvcConfigElement (
[hibernatetool] INSTANCEID number(19,0) not null,
[hibernatetool] oid varchar2(2048 char) not null,
[hibernatetool] ReferenceKey varchar2(2048 char),
[hibernatetool] InstanceName varchar2(255 char),
[hibernatetool] InstanceDescription varchar2(255 char),
[hibernatetool] requestedNE_ID number(19,0),
[hibernatetool] ProtocolIFType number(10,0),
[hibernatetool] InterfaceEncapType number(10,0),
[hibernatetool] Dlci number(10,0),
[hibernatetool] primary key (INSTANCEID)
[hibernatetool] );
[hibernatetool] alter table developer.IFRvcConfigElement
[hibernatetool] add constraint FK4C10C05A145A4B50b6728c4ace4cc838
[hibernatetool] foreign key (requestedNE_ID)
[hibernatetool] references developer.IACSrvcNEAssgnmntCnfgElmnt;
[hibernatetool] 2008-11-26 10:00:18,515 ERROR SchemaExport:274 - Unsuccessful: alter table developer.IFRvcConfigElement add constraint FK4C10C05A145A4B50b6728c4ace4cc838 foreign key (requestedNE_ID) references developer.IACSrvcNEAssgnmntCnfgElmnt
[hibernatetool] 2008-11-26 10:00:18,515 ERROR SchemaExport:275 - ORA-00972: identifier is too long
Debug level Hibernate log excerpt:
DEBUG
Problems with Session and transaction handling?
N/A
--
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
13 years, 1 month
[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
13 years, 1 month
[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
13 years, 1 month
[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
13 years, 1 month
[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
13 years, 1 month
[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
13 years, 1 month
[Hibernate-JIRA] Created: (HHH-2951) Restrictions.eq when passed null, should create a NullRestriction
by David Sheldon (JIRA)
Restrictions.eq when passed null, should create a NullRestriction
-----------------------------------------------------------------
Key: HHH-2951
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2951
Project: Hibernate3
Issue Type: Improvement
Components: query-criteria
Affects Versions: 3.2.1
Reporter: David Sheldon
Priority: Trivial
If you create a Restriction using eq, and pass null to it, then the generated SQL is "where foo = null", which always returns false.
The programmer will almost certainly have intended to get "where foo is null".
Ideally, we could change:
public static SimpleExpression eq(String propertyName, Object value) {
return new SimpleExpression(propertyName, value, "=");
}
to
public static SimpleExpression eq(String propertyName, Object value) {
if (value == null) {
return isNull(propertyName);
}
else {
return new SimpleExpression(propertyName, value, "=");
}
}
Unforunately that wont work, as isNull doesn't return a SimpleExpression.
--
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
13 years, 1 month
[Hibernate-JIRA] Created: (HHH-3950) org.hibernate.MappingException: Type not supported for auditing: org.hibernate.type.IdentifierBagType
by David Coleman (JIRA)
org.hibernate.MappingException: Type not supported for auditing: org.hibernate.type.IdentifierBagType
-----------------------------------------------------------------------------------------------------
Key: HHH-3950
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3950
Project: Hibernate Core
Issue Type: Bug
Components: envers
Affects Versions: 3.3.0.GA
Environment: JBoss Envers: jboss-envers-1.2.0.GA-hibernate-3.3 from org.jboss.envers (not on 3.5 of hibernate core yet)
Hibernate Core: hibernate-core-3.3.0.SP1.jar
JBoss + Seam
Reporter: David Coleman
Attachments: TypeIdentifierBagTypeNotSupportedTrace.txt
Hi,
I currenty have a problem with auditing a many-many relation in the entity show below. Initially I had the exact same problem as ´http://opensource.atlassian.com/projects/hibernate/browse/HHH-3843´' but on reading the documentation and releazing that the list contains duplicate elements, I add (as suggested) a @CollectionId annotation to get bag semantics.
Hoewever, the seam application fails to start-up due to the error being thrown from the envers module: "type not supported for auditing: org.hibernate.type.IdentifierBagType, on entity com.baratz.absys2.core.model.api.User, property 'roles'." (stack trace attached)
<snippet>
@Entity
@Audited
@Table(name = "USER_ABSYS")
public class User {
@UserRoles
@ManyToMany
@JoinTable(name = "USER_ROLE",
joinColumns = @JoinColumn(name = "UUNSEQ",unique=false) ,
inverseJoinColumns = @JoinColumn(name = "ROLE_ID",unique=false))
@TableGenerator(name = "UserRolesGen", table = "ABSYS_SEQUENCE", pkColumnName = "ID_NAME", valueColumnName = "NEXT_VAL", pkColumnValue = "USER_ROLE_ID_GEN", allocationSize=1)
@CollectionId(
columns = @Column(name="USER_ROLE_IDX"),
type=@Type(type="long"),
generator="UserRolesGen"
)
public List<Role> getRoles() {
return roles;
}
...
}
</snippet>
Regards,
Dave
--
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
13 years, 1 month
[Hibernate-JIRA] Created: (ANN-819) @Any mapping fails during configuration: "@Any requires an explicit @JoinColumn(s)"
by Noah Miller (JIRA)
@Any mapping fails during configuration: "@Any requires an explicit @JoinColumn(s)"
-----------------------------------------------------------------------------------
Key: ANN-819
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-819
Project: Hibernate Annotations
Issue Type: Bug
Affects Versions: 3.4.0.GA, 3.4.0.CR2, 3.4.0.CR1, 3.3.1.GA
Environment: Hibernate core 3.2.4.sp1 (reported in 3.3.1.GA as well)
Hibernate annotations 3.3.1.GA (reported in 3.4.0.GA as well)
Hibernate entity manager 3.3.1.ga
MySQL 5.0.45
Reporter: Noah Miller
When I try to apply the @Any annotation, I get the following exception:
ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] Error installing to Start: name=persistence.units:jar=test-build.jar,unitName=blueserve state=Create
org.hibernate.AnnotationException: @Any requires an explicit @JoinColumn(s): com.builderadius.blueserve.model.Note.noteOwner
at org.hibernate.cfg.AnnotationBinder.processElementAnnotations(AnnotationBinder.java:1201)
at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:739)
at org.hibernate.cfg.AnnotationConfiguration.processArtifactsOfType(AnnotationConfiguration.java:501)
at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:282)
at org.hibernate.cfg.Configuration.buildMappings(Configuration.java:1115)
at org.hibernate.ejb.Ejb3Configuration.buildMappings(Ejb3Configuration.java:1195)
at org.hibernate.ejb.EventListenerConfigurator.configure(EventListenerConfigurator.java:149)
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:814)
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:412)
at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:126)
at org.jboss.ejb3.entity.PersistenceUnitDeployment.start(PersistenceUnitDeployment.java:259)
See the forum posting http://forum.hibernate.org/viewtopic.php?p=2403045 for another description of this problem. That thread suggests the problem is with EJB3OverridenAnnotationReader not adding properties annotated with @JoinColumn if xml mapping files exist.
My code is:
@Any(metaColumn = @Column(name = "RelatedRecType"))
@AnyMetaDef(idType = "integer", metaType = "string", metaValues = {
@MetaValue(targetEntity = Approval.class, value = "approval"),
@MetaValue(targetEntity = ZoningPermit.class, value = "zoningpermit") })
@JoinColumn(name = "RelatedRecNum", nullable = false)
public BlueserveEntity getNoteOwner()
{
return this.noteOwner;
}
An orm.xml file (auto-generated by seam-gen) exists in this project, though it has no entity mappings and there are no other hbm.xml files. When I remove this file, I no longer receive the exception (that's not a long-term solution).
--
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
13 years, 1 month
[Hibernate-JIRA] Created: (HHH-3238) impossible to get the rowcount for a criteria that has projections
by hbMailingList (JIRA)
impossible to get the rowcount for a criteria that has projections
------------------------------------------------------------------
Key: HHH-3238
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3238
Project: Hibernate3
Issue Type: Bug
Affects Versions: 3.2.6
Environment: hibernate 3.2.6, oracle 10g
Reporter: hbMailingList
Projections.rowCount correctly returns the NUMBER_OF_ROWS for the criteria's resultset.
However if the criteria already has a projection then rowcount no longer returns the NUMBER_OF_ROWS in the result set.
For example:
Criteria c=session.CreateCriteria(Cat.class);
ProjectionList pl = ...;
....
pl.add(Projections.groupProperty("color"));
pl.add(Projections.rowCount());
c.setProjections(pl);
c.list();
will result in the following query:
select color, count(*) from cats group by color
I would expect it to result in:
select count(*) from (select color from cats group by color)
after all if I wanted the count by color I could have simply done:
Projections.count(...)
I really need this feature for my project...if you don't think this will make the release, would you please give me a hint and I'll submit a patch.
Thanks for all the hard work.
--
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
13 years, 1 month
[Hibernate-JIRA] Created: (HHH-2218) java.util.ConcurrentModificationException at org.hibernate.pretty.Printer.toString(Printer.java:90)
by rm (JIRA)
java.util.ConcurrentModificationException at org.hibernate.pretty.Printer.toString(Printer.java:90)
---------------------------------------------------------------------------------------------------
Key: HHH-2218
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2218
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.1.3
Environment: Hibernate 3.1.3, spring 2.1.8 on Jboss 4.0.2 with Oracle 10g
Reporter: rm
Similar issues have been logged since May 2005 and have been marked as 'Fixed' by Gavin especially for Session.toString() related cases. However, I am also facing similar issues in Printer.toString()...
The saving grace is that when I set the debug level to INFO, the problem goes away...
Am copy/pasting the relevent stacktrace...I have also debugged this on eclipse and the exact location is the call to "new Printer(....)" in AbstractFlushingEventListener.java
java.util.ConcurrentModificationException
10:07:28,421 INFO [STDOUT] at java.util.HashMap$HashIterator.nextEntry(HashMap.java:787)
10:07:28,421 INFO [STDOUT] at java.util.HashMap$ValueIterator.next(HashMap.java:817)
10:07:28,421 INFO [STDOUT] at org.hibernate.pretty.Printer.toString(Printer.java:90)
10:07:28,421 INFO [STDOUT] at org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:97)
10:07:28,421 INFO [STDOUT] at org.hibernate.event.def.DefaultAutoFlushEventListener.onAutoFlush(DefaultAutoFlushEventListener.java:35)
10:07:28,421 INFO [STDOUT] at org.hibernate.impl.SessionImpl.autoFlushIfRequired(SessionImpl.java:954)
10:07:28,421 INFO [STDOUT] at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1099)
10:07:28,421 INFO [STDOUT] at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79)
PS: This is my first attempt at logging issues at JIRA. Kindly point out any deficiencies or irregularities in this attempt.
--
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
13 years, 1 month
[Hibernate-JIRA] Created: (ANN-784) MapBinder.createFormulatedValue() does not honor DB schema name when creating query
by Sven Panko (JIRA)
MapBinder.createFormulatedValue() does not honor DB schema name when creating query
-----------------------------------------------------------------------------------
Key: ANN-784
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-784
Project: Hibernate Annotations
Issue Type: Bug
Components: binder
Affects Versions: 3.4.0.GA
Environment: Hibernate 3.3.0.SP1, PostgresQL 8.3
Reporter: Sven Panko
I detected a problem with a ManyToMany mapping using a Map in the following setup:
@Entity
@Table(name = "entitya", schema = "myschema")
class EntityA {
...
@ManyToMany(cascade = { CascadeType.PERSIST, CascadeType.MERGE })
@MapKey(name = "identifier")
@JoinTable(name = "entitya_entityb", schema="myschema", joinColumns = @JoinColumn(name = "entitya_pk"), inverseJoinColumns = @JoinColumn(name = "entityb_pk"))
@Cascade( { org.hibernate.annotations.CascadeType.SAVE_UPDATE, org.hibernate.annotations.CascadeType.DELETE_ORPHAN })
@Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
private Map<String, EntityB> entityBMap = new HashMap<String, EntityB>();
}
@Entity
@Table(name = "entityb", schema = "myschema")
class EntityB {
...
}
The SQL generated to load the entityBMap collection contains a subquery in the select clause, which looks like this:
select a8.identifier from entityb a8 where a8.pk=entityb0_.entityb_pk (entityb0_.entityb_pk comes from the outer select clause)
The problem here is, that entityb in the from clause is not prepended by the schema name "myschema" (the outer query is correctly doing this in the join clause, however). I tracked this down to the createFormulatedValue() method in the MapBinder class; the responsible code snippet is contained in lines 292 - 296:
StringBuilder fromAndWhereSb = new StringBuilder( " from " )
.append( associatedClass.getTable().getName() )
//.append(" as ") //Oracle doesn't support it in subqueries
.append( " " )
.append( alias ).append( " where " );
associatedClass.getTable().getName() does not return the fully qualified table name, so I think this should look something like this:
StringBuilder fromAndWhereSb = new StringBuilder( " from " );
if (associatedClass.getTable().getSchema() != null) {
fromAndWhereSb.append(associatedClass.getTable().getSchema()).append('.');
}
fromAndWhereSb.append( associatedClass.getTable().getName() )
//.append(" as ") //Oracle doesn't support it in subqueries
.append( " " )
.append( alias ).append( " where " );
--
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
13 years, 1 month
[Hibernate-JIRA] Created: (HHH-3502) getIdentifierMethod of BasicLazyInitializer does not match if method invoked through an interface with different return type
by Sean Bridges (JIRA)
getIdentifierMethod of BasicLazyInitializer does not match if method invoked through an interface with different return type
----------------------------------------------------------------------------------------------------------------------------
Key: HHH-3502
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3502
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 3.3.1
Reporter: Sean Bridges
Priority: Minor
I have an entity interface,
public interface IEntity {
public Object getId();
}
and I have an entity, say User that implements this interface with an id method
@Id
public Long getId() {
return id;
}
I can call getId() on an uninitialized proxy with,
user.getId()
however, if I call getId() in this way,
((IEntity) user)).getId()
I get org.hibernate.LazyInitializationException: could not initialize proxy - no Session
Looking at the code, BasicLazyInitializer has these lines,
else if ( isUninitialized() && method.equals(getIdentifierMethod) ) {
return getIdentifier();
}
the method.equals(getIdentifierMethod) returns false. The methods are not equal() because they have different return types (this is allowed in 1.5 with covariant return types).
Hibernate should not use Method.equals(), but should instead use the code below (modified from Method.equals(Object)),
public boolean equalsIgnoringReturnType(Method m1, Method m2) {
if ((m1.getDeclaringClass() != m2.getDeclaringClass()) {
return false;
}
if (m1.getName() != m2.getName()) {
return false;
}
Class[] params1 = m1.getParameterTypes();
Class[] params2 = m2.getParameterTypes();
if (params1.length != params2.length) {
return false;
}
for (int i = 0; i < params1.length; i++) {
if (params1[i] != params2[i])
return false;
}
return true;
}
--
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
13 years, 1 month
[Hibernate-JIRA] Created: (HHH-2744) QueryException raised for valid SQL query - problems with aliases parsing
by Michal Jastak (JIRA)
QueryException raised for valid SQL query - problems with aliases parsing
-------------------------------------------------------------------------
Key: HHH-2744
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2744
Project: Hibernate3
Issue Type: Bug
Affects Versions: 3.2.1
Environment: Tomcat 5.5, Hibernate Annotations 3.3.0 ga
Reporter: Michal Jastak
SQLQuery parser dose not parse queries correctly.
Trying to invoke:
session.createSQLQuery("select foo from bar where foo like '{%'");
ends with:
rg.hibernate.QueryException: Unmatched braces for alias path [select foo from bar where foo like '{%']
at org.hibernate.loader.custom.sql.SQLQueryParser.substituteBrackets(SQLQueryParser.java:74)
at org.hibernate.loader.custom.sql.SQLQueryParser.process(SQLQueryParser.java:51)
at org.hibernate.loader.custom.sql.SQLCustomQuery.<init>(SQLCustomQuery.java:110)
at org.hibernate.engine.query.NativeSQLQueryPlan.<init>(NativeSQLQueryPlan.java:43)
at org.hibernate.engine.query.QueryPlanCache.getNativeSQLQueryPlan(QueryPlanCache.java:114)
at org.hibernate.impl.AbstractSessionImpl.getNativeSQLQueryPlan(AbstractSessionImpl.java:137)
at org.hibernate.impl.AbstractSessionImpl.list(AbstractSessionImpl.java:142)
at org.hibernate.impl.SQLQueryImpl.list(SQLQueryImpl.java:152)
--
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
13 years, 1 month
[Hibernate-JIRA] Created: (HHH-3826) Hibernate 3.3.1.GA + Javassist issue 3.9.0.GA : java.lang.RuntimeException: by java.lang.NoClassDefFoundError: org/hibernate/proxy/HibernateProxy (OSGI Server)
by Charles Moulliard (JIRA)
Hibernate 3.3.1.GA + Javassist issue 3.9.0.GA : java.lang.RuntimeException: by java.lang.NoClassDefFoundError: org/hibernate/proxy/HibernateProxy (OSGI Server)
---------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-3826
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3826
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 3.3.1
Reporter: Charles Moulliard
Hi,
I try to use Hibernate 3.3.1.GA in combination with Spring OSGI 1.2.0-rc1. Unfortunately, there is a classloading issue on OSGI :
{code}
Caused by: java.lang.RuntimeException: by java.lang.NoClassDefFoundError: org/hibernate/proxy/HibernateProxy
at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:174)
at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.getProxyFactory(JavassistLazyInitializer.java:162)
... 58 more
Caused by: javassist.CannotCompileException: by java.lang.NoClassDefFoundError: org/hibernate/proxy/HibernateProxy
at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:167)
at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:170)
... 59 more
Caused by: java.lang.NoClassDefFoundError: org/hibernate/proxy/HibernateProxy
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
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:597)
at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:159)
... 60 more
{code}
remark : the package org.hibernate.proxy is defined in the MANIFEST file (section - Import-PAckage)
--
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
13 years, 1 month
[Hibernate-JIRA] Created: (HHH-4700) ClassCastException with parameter in CaseNode.getFirstThenNode()
by Jean-Baptiste Mille (JIRA)
ClassCastException with parameter in CaseNode.getFirstThenNode()
----------------------------------------------------------------
Key: HHH-4700
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4700
Project: Hibernate Core
Issue Type: Bug
Components: query-hql
Affects Versions: 3.3.2, 3.3.1, 3.3.0.SP1, 3.3.0.GA, 3.3.0.CR2, 3.3.0.CR1, 3.2.7, 3.2.6, 3.2.5, 3.2.4.sp1, 3.2.4, 3.2.3, 3.2.2, 3.2.1, 3.2.0.ga, 3.2.0.cr5, 3.2.0.cr4, 3.2.0.cr3, 3.2.0.cr2, 3.2.0 cr1
Environment: Hibernate 3.3.2.ga
Reporter: Jean-Baptiste Mille
Priority: Minor
Attachments: testcase.zip
Hql query with CASE .. WHEN and parameter in THEN clause throws a classCastException.
Example :
{code}
UPDATE MyObject SET myProperty = CASE WHEN myFilterProperty like 'L%' THEN :new_value END
{code}
Exception
java.lang.ClassCastException: org.hibernate.hql.ast.tree.ParameterNode cannot be cast to org.hibernate.hql.ast.tree.SelectExpression
at org.hibernate.hql.ast.tree.CaseNode.getFirstThenNode(CaseNode.java:44)
at org.hibernate.hql.ast.tree.CaseNode.getDataType(CaseNode.java:40)
at org.hibernate.hql.ast.tree.BinaryLogicOperatorNode.extractDataType(BinaryLogicOperatorNode.java:210)
at org.hibernate.hql.ast.tree.BinaryLogicOperatorNode.initialize(BinaryLogicOperatorNode.java:58)
at org.hibernate.hql.ast.HqlSqlWalker.prepareLogicOperator(HqlSqlWalker.java:1133)
at org.hibernate.hql.ast.HqlSqlWalker.evaluateAssignment(HqlSqlWalker.java:1043)
at org.hibernate.hql.antlr.HqlSqlBaseWalker.assignment(HqlSqlBaseWalker.java:1086)
at org.hibernate.hql.antlr.HqlSqlBaseWalker.setClause(HqlSqlBaseWalker.java:766)
at org.hibernate.hql.antlr.HqlSqlBaseWalker.updateStatement(HqlSqlBaseWalker.java:361)
at org.hibernate.hql.antlr.HqlSqlBaseWalker.statement(HqlSqlBaseWalker.java:239)
at org.hibernate.hql.ast.QueryTranslatorImpl.analyze(QueryTranslatorImpl.java:254)
at org.hibernate.hql.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:185)
at org.hibernate.hql.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:136)
at com.bnpparibas.eqd.DMLCaseTest.runQuery(DMLCaseTest.java:67)
at com.bnpparibas.eqd.DMLCaseTest.doesntWork(DMLCaseTest.java:35)
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:597)
at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:46)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
This issue have been [posted in user forum|https://forum.hibernate.org/viewtopic.php?f=1&t=981196&p=2369061&hi...].
It works with Hibernate 3.1.3.
A test case (designed for Hibernate 3.3.2.ga) which illustrate this issue is attached.
--
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
13 years, 1 month
[Hibernate-JIRA] Created: (HHH-4947) Silent exclusion of null-valued map entry
by Tsering Shrestha (JIRA)
Silent exclusion of null-valued map entry
-----------------------------------------
Key: HHH-4947
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4947
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.5.0-CR-1, 3.3.2
Reporter: Tsering Shrestha
<class name="Product">
<id name="id">
<generator class="native"/>
</id>
<map name="sellingPrice">
<key column="PRODUCT" not-null="true" foreign-key="FK_SP_PRODUCT"/>
<map-key type="string" column="model" not-null="true"/>
<element type="double" column="price" not-null="false"/>
</map>
</class>
Product product = new Product();
Product.getSellingPrice().put("XL",null);
Product.getSellingPrice().put("L", 34.90);
session.save(product)
Gives the following SQL:
insert into PRODUCT (id) values (null)
call identity()
insert into SELLINGPRICE (PRODUCT, MODEL, PRICE) values (?, ?, ?)
And the SELLINGPRICE table indeed only has one row. Why does Hibernately *silently* remove my null-valued entry? I would either want it to be able to save the entry or raise an exception that it cannot.
Report this post
--
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
13 years, 1 month
[Hibernate-JIRA] Created: (HHH-2031) Add functions to Dialect that can disable use of schema and catalog parts -- for HSQLDB support
by Brian Holmes (JIRA)
Add functions to Dialect that can disable use of schema and catalog parts -- for HSQLDB support
-----------------------------------------------------------------------------------------------
Key: HHH-2031
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2031
Project: Hibernate3
Type: Patch
Components: core
Versions: 3.1.3
Environment: This patch is against r9668 of /tags/v313/Hibernate3.
Reporter: Brian Holmes
Attachments: hibernate3-v313-support_schema_catalog_names.patch
HSQLDB does not support the use of three part names, that is Tables with schema and catalog parts.
This patch adds two functions to Dialect: supportsSchemaNames() and supportsCatalogNames(). Table.getQualifiedName() checks these values to decide whether to use or ignore the schema and catalog parts.
By default these are enabled in Dialect. This patch only disables their use in HSQLDialect.
This change is necessary for people who normally use Schema and Catalog names for access their primary database, but also use HSQLDB for Unit Testing. Without it, HSQLDB is unusable for Unit Testing because it fails on use of any catalog or schema names.
--
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
13 years, 2 months
[Hibernate-JIRA] Created: (HHH-4607) Deleted entities incorrectly reloaded within persistence context due to 2L cache
by Guenther Demetz (JIRA)
Deleted entities incorrectly reloaded within persistence context due to 2L cache
--------------------------------------------------------------------------------
Key: HHH-4607
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4607
Project: Hibernate Core
Issue Type: Bug
Components: caching (L2)
Affects Versions: 3.3.2
Environment: Hibernate3.3.2GA, SQLServer2008 used with COMMITED_READ isolation level
Reporter: Guenther Demetz
Attachments: TestCaseReloadAfterDelete.jar
Normally hibernate_session.get(entityName, id) returns null if the concerning entity is scheduled for removal, indipendently if the current context was already flushed or not, and this is also correct.
Attached testcase indeed shows, that with active 2Lcache
hibernate_session.get(entityName, id) suddenly and incorrectly returns the concerning entity again
if the deletion is already flushed and if in meantime another concurrent session do load the entity
(possible with COMMITED_READ isolation)!
Please see the attached testcase for detailed informations.
Here the output of the testcase:
15:37:30,417 INFO Version:15 - Hibernate Annotations 3.4.0.GA
15:37:30,446 INFO Environment:560 - Hibernate 3.3.2.GA
15:37:30,452 INFO Environment:593 - hibernate.properties not found
15:37:30,461 INFO Environment:771 - Bytecode provider name : javassist
15:37:30,470 INFO Environment:652 - using JDK 1.4 java.sql.Timestamp handling
15:37:30,580 INFO Version:14 - Hibernate Commons Annotations 3.1.0.GA
15:37:30,587 INFO Version:16 - Hibernate EntityManager 3.4.0.CR1
15:37:30,993 INFO AnnotationBinder:419 - Binding entity from annotated class: hello.Customer$Passport
15:37:31,048 INFO EntityBinder:422 - Bind entity hello.Customer$Passport on table Customer$Passport
15:37:31,141 INFO AnnotationBinder:419 - Binding entity from annotated class: hello.Customer
15:37:31,143 INFO EntityBinder:422 - Bind entity hello.Customer on table Customer
15:37:31,191 INFO AnnotationBinder:419 - Binding entity from annotated class: hello.A
15:37:31,193 INFO EntityBinder:422 - Bind entity hello.A on table A
15:37:31,206 INFO AnnotationBinder:419 - Binding entity from annotated class: hello.Messag
15:37:31,207 INFO EntityBinder:422 - Bind entity hello.Messag on table MESSAG
15:37:31,221 INFO AnnotationBinder:419 - Binding entity from annotated class: hello.SMS
15:37:31,224 INFO EntityBinder:422 - Bind entity hello.SMS on table SMS
15:37:31,240 INFO AnnotationBinder:419 - Binding entity from annotated class: hello.C
15:37:31,241 INFO EntityBinder:422 - Bind entity hello.C on table C
15:37:31,252 INFO AnnotationBinder:419 - Binding entity from annotated class: hello.B
15:37:31,254 INFO EntityBinder:422 - Bind entity hello.B on table B
15:37:31,257 INFO AnnotationBinder:419 - Binding entity from annotated class: hello.Amme
15:37:31,258 INFO EntityBinder:422 - Bind entity hello.Amme on table Amme
15:37:31,262 INFO AnnotationBinder:419 - Binding entity from annotated class: hello.Footballer
15:37:31,263 INFO EntityBinder:422 - Bind entity hello.Footballer on table Footballer
15:37:31,360 INFO CollectionBinder:650 - Mapping collection: hello.C.aggC -> C
15:37:31,370 INFO Version:17 - Hibernate Validator 3.1.0.GA
15:37:31,443 INFO HibernateSearchEventListenerRegister:53 - Unable to find org.hibernate.search.event.FullTextIndexEventListener on the classpath. Hibernate Search is not enabled.
15:37:31,503 INFO DriverManagerConnectionProvider:64 - Using Hibernate built-in connection pool (not for production use!)
15:37:31,504 INFO DriverManagerConnectionProvider:65 - Hibernate connection pool size: 20
15:37:31,505 INFO DriverManagerConnectionProvider:68 - autocommit mode: true
15:37:31,506 INFO DriverManagerConnectionProvider:72 - JDBC isolation level: READ_COMMITTED
15:37:31,658 INFO DriverManagerConnectionProvider:103 - using driver: com.microsoft.sqlserver.jdbc.SQLServerDriver at URL: jdbc:sqlserver://phx00081:1433;databasename=jpaexample
15:37:31,660 INFO DriverManagerConnectionProvider:109 - connection properties: {user=sa, password=****, autocommit=true, release_mode=auto}
15:37:32,305 INFO SettingsFactory:114 - RDBMS: Microsoft SQL Server, version: 10.00.1600
15:37:32,314 INFO SettingsFactory:115 - JDBC driver: Microsoft SQL Server JDBC Driver 2.0, version: 2.0.1803.100
15:37:32,353 INFO Dialect:175 - Using dialect: org.hibernate.dialect.SQLServerDialect
15:37:32,365 INFO TransactionFactoryFactory:62 - Transaction strategy: org.hibernate.transaction.JDBCTransactionFactory
15:37:32,367 INFO TransactionManagerLookupFactory:80 - No TransactionManagerLookup configured (in JTA environment, use of read-write or transactional second-level cache is not recommended)
15:37:32,367 INFO SettingsFactory:161 - Automatic flush during beforeCompletion(): disabled
15:37:32,368 INFO SettingsFactory:165 - Automatic session close at end of transaction: disabled
15:37:32,369 INFO SettingsFactory:180 - Scrollable result sets: enabled
15:37:32,370 INFO SettingsFactory:188 - JDBC3 getGeneratedKeys(): enabled
15:37:32,370 INFO SettingsFactory:196 - Connection release mode: auto
15:37:32,376 INFO SettingsFactory:223 - Default batch fetch size: 1
15:37:32,379 INFO SettingsFactory:227 - Generate SQL with comments: disabled
15:37:32,379 INFO SettingsFactory:231 - Order SQL updates by primary key: disabled
15:37:32,380 INFO SettingsFactory:235 - Order SQL inserts for batching: disabled
15:37:32,380 INFO SettingsFactory:397 - Query translator: org.hibernate.hql.ast.ASTQueryTranslatorFactory
15:37:32,384 INFO ASTQueryTranslatorFactory:47 - Using ASTQueryTranslatorFactory
15:37:32,385 INFO SettingsFactory:243 - Query language substitutions: {}
15:37:32,385 INFO SettingsFactory:248 - JPA-QL strict compliance: enabled
15:37:32,385 INFO SettingsFactory:253 - Second-level cache: enabled
15:37:32,386 INFO SettingsFactory:257 - Query cache: disabled
15:37:32,391 INFO SettingsFactory:382 - Cache region factory : org.hibernate.cache.impl.bridge.RegionFactoryCacheProviderBridge
15:37:32,392 INFO RegionFactoryCacheProviderBridge:61 - Cache provider: org.hibernate.cache.EhCacheProvider
15:37:32,398 INFO SettingsFactory:267 - Optimize cache for minimal puts: disabled
15:37:32,398 INFO SettingsFactory:276 - Structured second-level cache entries: disabled
15:37:32,404 INFO SettingsFactory:305 - Statistics: disabled
15:37:32,404 INFO SettingsFactory:309 - Deleted entity synthetic identifier rollback: disabled
15:37:32,405 INFO SettingsFactory:324 - Default entity-mode: pojo
15:37:32,405 INFO SettingsFactory:328 - Named query checking : enabled
15:37:32,474 INFO SessionFactoryImpl:193 - building session factory
15:37:32,496 WARN ConfigurationFactory:127 - No configuration found. Configuring ehcache from ehcache-failsafe.xml found in the classpath: jar:file:/home/pb00067/hibernate-distribution-3.3.2.GA/lib/optional/ehcache/ehcache-1.2.3.jar!/ehcache-failsafe.xml
15:37:32,552 WARN EhCacheProvider:93 - Could not find configuration [hello.A]; using defaults.
15:37:32,719 INFO PojoInstantiator:84 - no default (no-argument) constructor for class: hello.Customer$Passport (class must be instantiated by Interceptor)
15:37:32,841 INFO SessionFactoryObjectFactory:105 - Not binding factory to JNDI, no JNDI name configured
15:37:32,875 INFO SchemaExport:226 - Running hbm2ddl schema export
15:37:32,877 INFO SchemaExport:251 - exporting generated schema to database
15:37:32,960 INFO SchemaExport:268 - schema export complete
The problem stays probably in method DefaultLoadEventListener#doLoad:
as the delete-action is already flushed, the concerning entity is not present in the sessioncache
anymore, where it was previously marked as REMOVED
DefaultLoadEventListener#doLoad:
...
Object entity = loadFromSessionCache( event, keyToLoad, options );
if ( entity == REMOVED_ENTITY_MARKER ) {
log.debug( "load request found matching entity in context, but it is scheduled for removal; returning null" );
return null;
}
...
entity = loadFromSecondLevelCache(event, persister, options);
if ( entity != null ) {
...
return entity;
}
Afterwards doLoad attempts to load the entity from SecondLevelCache,
where in meantime it may be put again due another concurrent session.
N.B.: I believe the problem arises too if I would use JTA using the same transaction manager
for both hibernate and 2LC (JBoss).
best regards
G.D.
--
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
13 years, 2 months
[Hibernate-JIRA] Created: (HHH-3644) Add support for "WITH UR" isolation clause on DB2
by Ricardo Fernandes (JIRA)
Add support for "WITH UR" isolation clause on DB2
-------------------------------------------------
Key: HHH-3644
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3644
Project: Hibernate Core
Issue Type: Sub-task
Components: core
Affects Versions: 3.3.1
Environment: HIbernate 3.3.1 / DB2 9.x
Reporter: Ricardo Fernandes
The question is basically the same as Steve's, i.e. to force DB2 to use as few locks as possible on heavy load scenarios.
Although some might consider the use of the WITH UR clause a bad approach (since it allows dirty reads), the fact is that there are some cases where this is in fact acceptable, such as computing the total amount of rows of a query (for information purposes) or producing a high-level listing of items with very little detailed info. The bottom line is: if I need to trade performance for extremely accurate data, I surely want to be able to decide when this should happen.
I've already performed the changes that makes it possible to use both the FOR READ ONLY and the WITH UR clauses and I will be submitting a patch shortly so you can have a look at it. The strategy I've used was basically the following:
1. Added two new methods on the Dialect class:
String getDatabaseReadOnlyString(String sql) - for adding the READ ONLY clause
String getDirtyReadsString(String sql) - for adding the WITH UR clause
2. Changed the Query interface in order to allow the user to say whether he/she wants the query to allow dirty reads:
Query setAllowDirtyReads(boolean allowDirtyReads);
3. Added a default implementation on the AbstractQueryImpl which initializes the flag a false
4. Added a similar attribute on the QueryParameters class
5. Changed the prepareQueryStatement() method of the Loader class (just after the useLimit part in order:
a) Ask the dialect for the getDatabaseReadOnlyString() is there are no LockModes set (as did Steve)
b) Ask the dialect for the getDirtyReadsString() is the queyParameters allows dirty reads.
All the tests were well succeeded.
Hope you find these changes, at least, worth looking at.
Best Regards,
Ricardo
--
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
13 years, 2 months
[Hibernate-JIRA] Created: (HHH-3458) Register postgres random() function as "rand" in PostgresSQLDialect
by Stephen Cresswell (JIRA)
Register postgres random() function as "rand" in PostgresSQLDialect
-------------------------------------------------------------------
Key: HHH-3458
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3458
Project: Hibernate3
Issue Type: Improvement
Components: build
Affects Versions: 3.2.5
Environment: Postgres 8.3
Reporter: Stephen Cresswell
Priority: Trivial
I have an HQL query which uses "order by rand()". This works fine in our local integration tests (which are run against hsqldb), but fails against our build integration tests which runs postgres.
The reason the query fails is because postgres function for "rand" is called "random". We can workaround this by dynamically detecting the db driver and generating db specific queries, but it strikes me that the cleanest solution for this is to simply re-register postgres' random function as "rand" in the PostgresSQLDialect, i.e.
registerFunction( "random", new NoArgSQLFunction("random", Hibernate.DOUBLE) );
registerFunction( "rand", new NoArgSQLFunction("random", Hibernate.DOUBLE) );
--
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
13 years, 2 months
[Hibernate-JIRA] Created: (HHH-2448) Generate identical column aliases among cluster
by Loïc LEFEVRE (JIRA)
Generate identical column aliases among cluster
-----------------------------------------------
Key: HHH-2448
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2448
Project: Hibernate3
Type: Improvement
Components: query-sql
Versions: 3.2.2
Environment: Hibernate version: 3.2.2, 2.1.8
Database: Oracle 9.2.0.8
Reporter: Loïc LEFEVRE
Attachments: report_1.txt, report_2.txt
Among our weblogic cluster (12 instances), we can see that a query can have different column aliases.
Although all seems correct, when regarding database reports like StatsPack or Spotlight we can see that because of these different aliases, the reports are wrong. Indeed, a resource consuming query can see its associated report properties (cpu usage, buffer gets, number of executions...) divided by the number of weblogic instances of our cluster (i.e. divided by 12) thus preventing us to pinpoint the queries to look at.
On a 3 instances cluster, we can see this report:
REPORT#1: one statement with a poor number of buffer gets/execution is reported splitted in 3, see the alias generated for column DTO.CREATION_DATE
for example
On a 4 instances cluster, we can see this report:
REPORT#2: one statement responsible of the latch free/cache buffers chains wait events splitted in 4, note the column alias generated fordeffcashcy0_.BEST_EXPECTED_CY
More than confusing the DBAs about the same query with n different "faces", our reports don't show us all the queries to look at: indeed, in our "Top 50 queries", a lot of them are duplicates! Also the memory required in the SGA to store the queries, the execution plan and so on is increased...
Finally, although the column aliases can have up to 30 characters under Oracle, the limit is set to 10, why?
--
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
13 years, 2 months
[Hibernate-JIRA] Created: (HHH-5255) Bytecode instrumented byte[] lazy properties do not work
by Kyrill Alyoshin (JIRA)
Bytecode instrumented byte[] lazy properties do not work
--------------------------------------------------------
Key: HHH-5255
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5255
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.5.2
Environment: Hibernate-3.5.2, Oracle 10g
Reporter: Kyrill Alyoshin
Well, I have an entity that stores a byte[] property as a Blob.
@Lob
@Basic(optional = false, fetch = FetchType.LAZY)
public byte[] getContent() {
return content;
}
The content can be pretty large, so I marked it as lazy and to enable lazy property fetching I am instrumenting the class at build-time using org.hibernate.tool.instrument.javassist.InstrumentTask just as the documentation says.
However, when I call session.merge on this entity, I can get this stacktrace:
java.lang.ClassCastException: org.hibernate.intercept.LazyPropertyInitializer$1 cannot be cast to [B
at org.hibernate.type.AbstractLongBinaryType.toInternalFormat(AbstractLongBinaryType.java:46)
at org.hibernate.type.AbstractBynaryType.isEqual(AbstractBynaryType.java:134)
at org.hibernate.type.NullableType.isEqual(NullableType.java:233)
at org.hibernate.type.MutableType.replace(MutableType.java:60)
at org.hibernate.type.TypeFactory.replace(TypeFactory.java:548)
at org.hibernate.event.def.DefaultMergeEventListener.copyValues(DefaultMergeEventListener.java:495)
at org.hibernate.event.def.DefaultMergeEventListener.entityIsDetached(DefaultMergeEventListener.java:423)
at org.hibernate.event.def.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:234)
at org.hibernate.event.def.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:84)
at org.hibernate.impl.SessionImpl.fireMerge(SessionImpl.java:859)
at org.hibernate.impl.SessionImpl.merge(SessionImpl.java:843)
at org.hibernate.impl.SessionImpl.merge(SessionImpl.java:847)
It seems to work fine on session.get()
I think it is a bug.
--
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
13 years, 2 months
[Hibernate-JIRA] Created: (HHH-3811) Bug: No ability to escape SQL keywords in HQL queries.
by John Roberts (JIRA)
Bug: No ability to escape SQL keywords in HQL queries.
------------------------------------------------------
Key: HHH-3811
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3811
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.0.CR1
Environment: 3.3.0.CR1, MS SQL Server 2005 Express
Reporter: John Roberts
Priority: Critical
There appears to be no way to escape property names that are SQL keywords in HQL queries. For example, if you have a property named "key", which is a reasonable name for a property, and you are constructing an HQL query, e.g.:
session.createQuery("select from Entities where key=?");
That will fail on MS SQL Server, because "key" is a reserved T-SQL keyword. However, there is no way to make it succeed, as either an absent-minded developer appears to have forgotten to add the ability to escape keywords to HQL (oops), or it's the secret of the millennium and was left out of the documentation on purpose (it has certainly boggled the minds of the folks on FreeNode #java, #hibernate, and the hibernate forum). Note that none of the following will succeed (this is what I have tried so far):
session.createQuery("select from Entities where key=?");
session.createQuery("select from Entities where [key]=?"); // <-- mssql style still fails to be parsed
session.createQuery("select from Entities where `key`=?");
session.createQuery("select from Entities where 'key'=?");
session.createQuery("select from Entities where \"key\"=?");
session.createQuery("select from Entities where ''key''=?");
session.createQuery("select from Entities where {key}=?");
session.createQuery("select from Entities where <key>=?");
session.createQuery("select from Entities where (key)=?");
session.createQuery("select from Entities where $key$=?");
session.createQuery("select from Entities where $key=?");
Note that using the underlying DBMS's escape method *does* work for column names in the entity mappings, but does not work in actual HQL.
Since most DBMS's have their own dialects of SQL, the inability to escape keywords in HQL means that it is generally impossible to guarantee that any given HQL query will work unless you specifically design your application around the underlying DBMS (which is precisely one of the things you were hoping to avoid with Hibernate -- although on the other hand you're already tied to the DBMS with escaped keywords in the entity mapping anyways).
--
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
13 years, 2 months
[Hibernate-JIRA] Created: (HHH-3818) Hibernate/JBC integration doesn't property handle Entity/CollectionRegionAccessStrategy evict
by Brian Stansberry (JIRA)
Hibernate/JBC integration doesn't property handle Entity/CollectionRegionAccessStrategy evict
---------------------------------------------------------------------------------------------
Key: HHH-3818
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3818
Project: Hibernate Core
Issue Type: Bug
Components: caching (L2)
Affects Versions: 3.3.1
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 3.3.x
EntityRegionAccessStrategy and CollectionRegionAccessStrategy have evict(Object key) and evictAll() that say they must cause removal of items from the cache "immediately without regard for transaction isolation." The Hibernate/JBC integration is not properly handling this as the JBC removeNode calls it makes are not dealing with transactional issues. The integration needs to:
1) Perhaps suspend any ongoing tx (particularly since these calls are typically made from a tx Synchronization's afterCompletion() callback, when the tx is Status.COMMITTED and it isn't appropriate to call into the cache expecting the cache to incorporate the call into the transaction. (Alhthough I believe JBC handles this correctly by ignoring the tx, since it isn't ACTIVE).
2) Deal with the fact that the tx that is being committed is likely holding locks in JBC. This is the big issue. I believe dealing with this will a) require keeping state in the Hib/JBC integration layer's Region to track that an eviction has occurred but may not be reflected in JBC b) using JBC as a notification bus to propagate the fact of the eviction to other nodes c) attempting to evict the data from JBC locally, failing promptly in the face of lock conflicts d) including in any get() or putFromLoad() calls logic to check the state from a), again attempting to evict locally (with a very short timeout) if not yet evicted and not allowing calls to proceed into JBC until successful.
--
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
13 years, 2 months
[Hibernate-JIRA] Created: (HHH-4857) Sharing some of the config info from Ejb3Configuration and SessionFactoryImpl
by Chris Baxter (JIRA)
Sharing some of the config info from Ejb3Configuration and SessionFactoryImpl
-----------------------------------------------------------------------------
Key: HHH-4857
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4857
Project: Hibernate Core
Issue Type: New Feature
Components: core, entity-manager
Reporter: Chris Baxter
Priority: Minor
In our system, we have each clients data in a separate DB instance. We're using JPA (via hibernate) on top of that to get at the data. The problem here is that for each client DB supported by one of our jboss servers, we have to have an instance of EntityManagerFactory compete with an Ejb3Configuration instance. Each config instance takes up around 20 MBs of permanent space, so if we have have 1000 client DBs supported by a jboss instance, it takes up a hugh amount of memory for information that will always be the same (the DB schemas are always the exact same in each client DB) across all EntityManagerFactory instances. So what I want to know is if there is a way to only have one instance of Ejb3Configuration that can be shared across all of the EntityManagerFactory instances that are spawning my EntityManagers. This would be huge as it would help me save many gigs of memory that never can be collected (old gen in jboss).
I prototyped some changes locally to Ejb3Configuration (to allow an instance of AnnotationConfiguration to be supplied in the constructor, allowing sharing across all instanced of this class) and to SessionFactoryImpl (to share some of the properties like entityPersisters, classMetadata and such) and I was able to reduce the footprint to 20 MBs for the first DB and then under a MB for each additional DB. The changes I made were a bit quick and dirty though, just to see if it was possible. So I'm taking out this feature request to see if this is a piece of work that you guys can do (or I can contribute after refactoring to a more suitable approach) and integrate into the main code for hibernate-core and hibernate-entitymanager. Let me know if this is something you guys think to be a valuable addition.
--
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
13 years, 2 months
[Hibernate-JIRA] Created: (HHH-3465) HiRDB Support
by Tomoto Shimizu Washio (JIRA)
HiRDB Support
-------------
Key: HHH-3465
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3465
Project: Hibernate3
Issue Type: New Feature
Components: core
Affects Versions: 3.2.5
Environment: 3.2.5 + HiRDB V8 + Type4 JDBC Driver
Reporter: Tomoto Shimizu Washio
Attachments: hirdbdialect.patch
I would like to contribute with a dialect for HiRDB, Hitachi's RDBMS.
(For more information, please see http://www.hitachi.co.jp/Prod/comp/soft1/global/prod/hirdb/)
I added 4 classes and slightly modified 2 existing classes as shown below. Please look at the documentation at the top of the patch for explanations.
org.hibernate.dialect.HiRDBDialect (added)
org.hibernate.dialect.UserFuncDeclParser (added)
org.hibernate.dialect.DialectFactory (modified)
org.hibernate.dialect.function.AnsiTrimEmulationFunction (modified)
org.hibernate.dialect.function.AnsiTrimEmulationFunctionWithTrimstrs (added)
org.hibernate.dialect.function.TypeQualifiedSQLFunction (added)
You may think this code is relatively large as a dialect. It is because I also implemented user-defined function support. As HiRDB requires '?' parameters to be qualified by 'as <type>' in user-defined function invocations, I made a parser for the type declarations that the user specified in the properties file, and a renderer for the type qualifier. See javadoc comments of HiRDBDialect and UserFuncDeclParser for more details.
This patch is created on Hibernate 3.2.5.ga and tested on HiRDB V8 with Type4 JDBC Driver. The example configuration for HiRDB is shown below:
hibernate.dialect org.hibernate.dialect.HiRDBDialect
hibernate.connection.driver_class JP.co.Hitachi.soft.HiRDB.JDBC.HiRDBDriver
hibernate.connection.url jdbc:hitachi:hirdb://DBID=@HIRDBENVGRP=C:/hirdb.ini
hibernate.connection.username hitachi
hibernate.connection.password hitachi
--
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
13 years, 2 months