[Hibernate-JIRA] Created: (HHH-2094) Hibernate is ignoring native sql aliases and generating "column not found" error
by Leonardo Penczek (JIRA)
Hibernate is ignoring native sql aliases and generating "column not found" error
--------------------------------------------------------------------------------
Key: HHH-2094
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2094
Project: Hibernate3
Type: Bug
Components: query-sql
Versions: 3.2.0.cr4
Environment: 3.2.0.cr4, Adaptive Server Enterprise/12.5.3
Reporter: Leonardo Penczek
Priority: Critical
As simples as that:
1: Query q = em.createNativeQuery("select cd_person as codePerson, cd_person as identif from PERSON");
2: List<Object[]> resultList = (List<Object[]>) q.getResultList();
Hibernate is ignoring my aliases when retrieving information from the ResultSet because it is trying to retrieve by column name, generating the following error:
javax.persistence.PersistenceException: org.hibernate.exception.SQLGrammarException: could not execute query
at org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:641)
at org.hibernate.ejb.QueryImpl.getResultList(QueryImpl.java:73)
at <my line 2 in the code above>
...
Caused by: org.hibernate.exception.SQLGrammarException: could not execute query
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:67)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
at org.hibernate.loader.Loader.doList(Loader.java:2147)
at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2028)
at org.hibernate.loader.Loader.list(Loader.java:2023)
at org.hibernate.loader.custom.CustomLoader.list(CustomLoader.java:289)
at org.hibernate.impl.SessionImpl.listCustomQuery(SessionImpl.java:1695)
at org.hibernate.impl.AbstractSessionImpl.list(AbstractSessionImpl.java:142)
at org.hibernate.impl.SQLQueryImpl.list(SQLQueryImpl.java:150)
at org.hibernate.ejb.QueryImpl.getResultList(QueryImpl.java:64)
...
Caused by: java.sql.SQLException: S0022: Invalid column name 'cd_person'.
at com.sybase.jdbc3.jdbc.ErrorMessage.raiseError(Unknown Source)
at com.sybase.jdbc3.tds.TdsResultSet.findColumnByLabel(Unknown Source)
at com.sybase.jdbc3.jdbc.SybResultSet.findColumn(Unknown Source)
at com.sybase.jdbc3.jdbc.SybResultSet.getInt(Unknown Source)
at org.jboss.resource.adapter.jdbc.WrappedResultSet.getInt(WrappedResultSet.java:690)
at org.hibernate.type.IntegerType.get(IntegerType.java:28)
at org.hibernate.type.NullableType.nullSafeGet(NullableType.java:113)
at org.hibernate.type.NullableType.nullSafeGet(NullableType.java:139)
at org.hibernate.loader.custom.CustomLoader$ScalarResultColumnProcessor.extract(CustomLoader.java:474)
at org.hibernate.loader.custom.CustomLoader$ResultRowProcessor.buildResultRow(CustomLoader.java:420)
at org.hibernate.loader.custom.CustomLoader.getResultColumnOrRow(CustomLoader.java:317)
at org.hibernate.loader.Loader.getRowFromResultSet(Loader.java:594)
at org.hibernate.loader.Loader.doQuery(Loader.java:689)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
at org.hibernate.loader.Loader.doList(Loader.java:2144)
Awesome! The SQL query runs, but the Hibernate try to get the column by the original name, not by the alias, causing the error!
It is not possible to correctly get the value of 2 different columns that have the same name!!!!
Hint: why Hibernate use ResultSet.get* by column name instead of positional ResultSet.get* (1, 2, 3,...)? It will solve this problem.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
14 years, 11 months
[Hibernate-JIRA] Created: (HHH-2676) Cannot apply UPGRADE lock to scalar Query object
by John Wood (JIRA)
Cannot apply UPGRADE lock to scalar Query object
------------------------------------------------
Key: HHH-2676
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2676
Project: Hibernate3
Issue Type: Bug
Components: query-hql
Affects Versions: 3.1
Reporter: John Wood
Priority: Minor
Attachments: Bean.hbm.xml, Bean.java
If you try and add a lock to a Query object (against a named alias) when doing a scalar HQL query (e.g. "select sum(foo) from bah") then an error occurs.
The sample code (full working example is attached):
// Create query
Query q = session.createQuery("select b.value from Bean b");
// Set lock mode on query
q.setLockMode("b", LockMode.UPGRADE);
// Executre
q.list();
This causes the following error:
Exception in thread "main" java.lang.IllegalArgumentException: could not locate alias to apply lock mode : b
at org.hibernate.loader.hql.QueryLoader.applyLocks(QueryLoader.java:297)
at org.hibernate.loader.Loader.preprocessSQL(Loader.java:201)
at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1538)
at org.hibernate.loader.Loader.doQuery(Loader.java:673)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236)
at org.hibernate.loader.Loader.doList(Loader.java:2220)
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)
I have tried this both with an older version of Hibernate (3.1) and the latest with the same result (although the older Hibernate has the error message "alias not found".
I have attached a simple example to demonstrate this.
See also HHH-1965.
Perhaps, it is simply that one cannot lock scalar queries of this type. If so, then the fix would presumably be to include this in the Query class Javadocs.
--
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
14 years, 11 months
[Hibernate-JIRA] Created: (HHH-2146) NullpointerException in DefaultDeleteEventListener.deleteTransientEntity
by Martin Kartumovich (JIRA)
NullpointerException in DefaultDeleteEventListener.deleteTransientEntity
------------------------------------------------------------------------
Key: HHH-2146
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2146
Project: Hibernate3
Type: Bug
Versions: 3.2.0.cr5
Environment: Hibernate 3.2.0cr5, Oracle10g
Reporter: Martin Kartumovich
Priority: Blocker
The following setup leads to a NPE in DefaultDeleteEventListener.deleteTransientEntity:
Tables A, B
Table V_A_B that is an M-N-Connection between A and B.
Pojo for A has a Set of V_A_Bs.
Pojo for B has a Set of V_A_Bs.
Pojo C that has Sets of As and Bs.
Cascades: all, delete-orphan
-Create a new A and add a new V_A_B to its Set, that references to an existing B.
-Delete B.
-SaveOrUpdate Pojo C.
In Hibernate 3.1.3 this works fine.
In 3.2.0cr4+cr5 the removal of B results into an cascading removal of the never persisted V_A_B in the Set of B instead of ignoring it.
This leads to an incorrect state where deleteTransientEntity is called with transientEnties=null.
When now calling transientEnties.contains(...) the NPE is thrown.
--
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
14 years, 12 months
[Hibernate-JIRA] Created: (HHH-2624) NullPointerException when Query.list()
by Eddie Man (JIRA)
NullPointerException when Query.list()
--------------------------------------
Key: HHH-2624
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2624
Project: Hibernate3
Issue Type: Bug
Components: core
Environment: MySQL database
Reporter: Eddie Man
Priority: Critical
Attachments: src.zip
The following exception was thrown when I calling Query.list():
Exception in thread "main" java.lang.NullPointerException
at org.hibernate.persister.entity.AbstractEntityPersister.loadByUniqueKey(AbstractEntityPersister.java:1641)
at org.hibernate.type.EntityType.loadByUniqueKey(EntityType.java:608)
at org.hibernate.type.EntityType.resolve(EntityType.java:382)
at org.hibernate.engine.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:116)
at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:842)
at org.hibernate.loader.Loader.doQuery(Loader.java:717)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
at org.hibernate.loader.Loader.doList(Loader.java:2211)
at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2095)
at org.hibernate.loader.Loader.list(Loader.java:2090)
Reference issue :
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-48
Steps for reproduce the problem
==================
1. Unzip the attached file.
2. Execute the "schema.ddl" to create the tables.
3. Execute the "data.ddl" to insert the simple records.
4. Compile the src, and run the Main class.
--
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
14 years, 12 months
[Hibernate-JIRA] Created: (HHH-2399) FlushMode.AUTO practically unusable - should not flush before EVERY query
by Piotr Kołaczkowski (JIRA)
FlushMode.AUTO practically unusable - should not flush before EVERY query
-------------------------------------------------------------------------
Key: HHH-2399
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2399
Project: Hibernate3
Type: Improvement
Versions: 3.1.3, 3.2.1, 3.2.2, 3.2.0.ga
Environment: PostgreSQL 8.1.5, JDBC 2 and 3, Linux kernel 2.4.x, 2.6.x, Java 1.5.0_09
Reporter: Piotr Kołaczkowski
Attachments: hbtest.zip
The method flushIfRequired seems to flush before every query execution, even though there wasn't anything changed to the objects in the session, and the objects in the session are of different class than the object(s) queried. When having more than a few such objects in a session, it may lead to large, unneeded overheads (I noticed 10-200 times slowdown on simple queries). Our system uses many fast queries, that uasually return only one result or few results. The average query durations on different levels, measured by System.nanoTime() (see the attachment):
- database level: 0.05 ms
- pure JDBC code, prepared statements: 0.2 ms
- pure JDBC code, no prepared statements: 0.7 ms
- not cached hibernate query, no other objects associated with the session: 1.3 ms
- cached hibernate query, object in the session cache, no other objects associated with the session: 1.1 ms
- cached hibernate query, 10000 very simple objects of some other class in the session: >50 ms
10000 may seem large, but note these were very simple objects, having only 2 properties. On our production system we have classes with many properties, and even 20 objects in a session can cause a sub-millisecond query to run longer than 5 ms. We switched to FlushMode.COMMIT, and now the performance is much better.
Can you do something about this? As far as I've read in JIRA, a similar issue exists in Hibernate 2.x, and is still OPEN / UNRESOLVED.
BTW. Why is the 1st level cache so slow in my tests? Why reading just a 2 field object from the database cause so much overhead over pure JDBC? What am I doing wrong?
There is so much marketing about using cglib reflection optimizer in the performance FAQ but even if I retrieved these objects using JDBC and reflection, I would achieve much better performance. After all 1 ms is very much time, if getting results from DB and sending them to JVM lasts 0.2 ms.
--
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
15 years
[Hibernate-JIRA] Created: (HHH-2347) Improvement to DerbyDialect default identy generation mode
by Fabrizio Giustina (JIRA)
Improvement to DerbyDialect default identy generation mode
----------------------------------------------------------
Key: HHH-2347
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2347
Project: Hibernate3
Type: Patch
Versions: 3.2.1
Reporter: Fabrizio Giustina
Attachments: DerbyDialect-identity.diff
although derby supports identities org.hibernate.dialect.DerbyDialect strangely uses an HiLo generation strategy for ids (for any other dialects that support identities IdentityGenerator is the default).
Even more curiously, DerbyDialect overrides getIdentityColumnString() from the Db2 dialect by using "generated ALWAYS as identity" instead of "generated BY DEFAULT as identity". Derby however fully supports "by default" in identities as clarified in http://db.apache.org/derby/docs/10.1/ref/rrefsqlj37836.html .
"by default" should be preferred since it allows a direct insertion when needed (and I can't see no reason why enabling it for db2 and not for derby).
The patch attached simply deletes two methods, so that the default implementation from Db2Dialect is used:
- removing getIdentityColumnString() make derby use "by default" identities like db2 already does
- removing getNativeIdentifierGeneratorClass() make it choose IdentityGenerator.class (it falls back to the default strategy used in org.hibernate.dialect.Dialect)
note that part of this issue has already been reported in HHH-1918 (not addressing the identity generation string)
--
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
15 years
[Hibernate-JIRA] Created: (HHH-2413) Offer a way to log bound jdbc parameters in a uniform way for UserType implementors
by Baptiste MATHUS (JIRA)
Offer a way to log bound jdbc parameters in a uniform way for UserType implementors
-----------------------------------------------------------------------------------
Key: HHH-2413
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2413
Project: Hibernate3
Type: Improvement
Versions: 3.2.2
Reporter: Baptiste MATHUS
Priority: Minor
At the moment, when someone implements a UserType, the bound parameters won't be displayed in not explicitly displayed via loggers.
For example, here is what the code of NullableType.nullSafeGet() is :
public final void nullSafeSet(PreparedStatement st, Object value, int index)
throws HibernateException, SQLException {
try {
if ( value == null ) {
if ( IS_TRACE_ENABLED ) {
log().trace( "binding null to parameter: " + index );
}
st.setNull( index, sqlType() );
}
else {
if ( IS_TRACE_ENABLED ) {
log().trace( "binding '" + toString( value ) + "' to parameter: " + index );
}
set( st, value, index );
}
}
catch ( RuntimeException re ) {
log().info( "could not bind value '" + toString( value ) + "' to parameter: " + index + "; " + re.getMessage() );
throw re;
}
catch ( SQLException se ) {
log().info( "could not bind value '" + toString( value ) + "' to parameter: " + index + "; " + se.getMessage() );
throw se;
}
}
IMO, it would be quite a good thing to provide some method in Hibernate, something like logBoundParameter() that would do the log like above :
> log().trace( "binding '" + toString( value ) + "' to parameter: " + index );
This method could then be just called by implementors so as to guaranty the display is always the same about bound parameters.
Even more, I think it should use a special logger, just like the org.hibernate.SQL one to display this parameters. In fact, at the moment, I feel the reference documentation is not very clear about this : see http://www.hibernate.org/hib_docs/v3/reference/en/html/session-configurat.... It says :
> org.hibernate.type Log all JDBC parameters
But that's not completely true: it will only log bound parameters that are parameters typed with standard types coming from the org.hibernate.type package. Any custom UserType won't display anything until you:
1) put the right log4j line for the package where your userType is located ;
2) think about explicitly logging those parameter values in your custom UserType (cf. my first point).
I'm not sure I made myself totally clear,. If so, please let me know.
If you think that would be worth an improvement, I'll give a look to provide a patch for this. Thanks a lot.
--
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
15 years
[Hibernate-JIRA] Created: (HHH-2845) "Another ORA-00907: missing right parenthesis" bug with Oracle
by Dean Pullen (JIRA)
"Another ORA-00907: missing right parenthesis" bug with Oracle
--------------------------------------------------------------
Key: HHH-2845
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2845
Project: Hibernate3
Issue Type: Bug
Affects Versions: 3.2.5
Environment: hibernate-entitymanager.jar (3.3.1ga)
hibernate-annotations.jar (v 3.3.0ga)
hibernate-commons-annotations.jar (within Hibernate Annotations.rar\lib)
ejb3-persistence.jar (within Hibernate Annotations.rar\lib)
hibernate3.jar (v 3.2.5.ga)
Oracle 10g
Reporter: Dean Pullen
I'm using JBoss 4.2.1GA, with the Hibernate environment described above, using Oracle 10g, and attempting to perform a query.
I've been receiving a "ORA-00907: missing right parenthesis" error when attempting to perform the query.
Now a similar bug had this down to Hibernate using the 'as' keyword in the query, aliasing the table name - something that has been fixed in Hibernate 3.3.0ga.
(Aliasing a table in the SQL spec is optional, Oracle doesn't support it)
But I still get the same error. The query still contains the 'as' keyword (but not aliasing a table)
Here is an example:
I have two tables. CSIUsers and CSIUserSurveys.
There is a one-to-many mapping between CSIUsers to CSIUserSurveys.
Query query = entityManager.createQuery("FROM " + CSIUser.class.getSimpleName()
+ " cu LEFT JOIN cu.csiUserSurveys us"
+ " WHERE NOT EXISTS (SELECT us FROM cu.csiUserSurveys us WHERE us.csiUserId = cu.csiUserId)");
Result:
[[14 Sep 2007 15:43:52] DEBUG org.hibernate.util.JDBCExceptionReporter - could n
ot execute query [select csiuser0_.CSI_USER_ID as CSI1_15_0_, csiusersur1_.CSI_U
SER_ID as CSI1_16_1_, csiusersur1_.SURVEY_TYPE_CODE as SURVEY2_16_1_, csiuser0_.
COMPANY_CODE as COMPANY2_15_0_, csiuser0_.EMAIL_ADDRESS as EMAIL3_15_0_, csiuser
0_.FAILED_LOGINS as FAILED4_15_0_, csiuser0_.LOCALE as LOCALE15_0_, csiuser0_.PA
SSWORD as PASSWORD15_0_, csiuser0_.PURCHASE_DATE as PURCHASE7_15_0_, csiuser0_.S
TATUS as STATUS15_0_, csiuser0_.USER_NAME as USER9_15_0_, csiuser0_.USER_PRIVILE
GE as USER10_15_0_, csiusersur1_.SURVEY_INVITE_DATE as SURVEY3_16_1_ from CSI_US
ERS csiuser0_ left outer join CSI_USER_SURVEYS csiusersur1_ on csiuser0_.CSI_USE
R_ID=csiusersur1_.CSI_USER_ID where not (exists (select (csiusersur2_.CSI_USER_
ID, csiusersur2_.SURVEY_TYPE_CODE) from CSI_USER_SURVEYS csiusersur2_ where csiu
ser0_.CSI_USER_ID=csiusersur2_.CSI_USER_ID and csiusersur2_.CSI_USER_ID=csiuser0
_.CSI_USER_ID))]
java.sql.SQLException: ORA-00907: missing right parenthesis
--
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
15 years