[Hibernate-JIRA] Created: (HHH-1994) Problem with case sensitive column and tables names and Identity mapping with postgreSQL
by Alex Samad (JIRA)
Problem with case sensitive column and tables names and Identity mapping with postgreSQL
----------------------------------------------------------------------------------------
Key: HHH-1994
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1994
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.1.3
Environment: Hibernate 3.1.3, Java 1.5.0_07 (sun) windos and linux ( 32 & 64 bit). POstgres SQL 8.1 Windows and linux
Reporter: Alex Samad
Whilst trying to insert into a table with a primary key (ID mapping) which has a identity generator. And the columns and/or the table has been defined with case sensitivey ie back ticks.
It fails to get the next serial number and thus fails any inserts.
The problem lies in dialect/PostgreSQLDialect.java
public String getIdentitySelectString(String table, String column, int type) {
return new StringBuffer().append("select currval('")
.append(table)
.append('_')
.append(column)
.append("_seq')")
.toString();
}
table is inclosed in quotes and column is inclosed in quotes which gives a name like
"table"_"Column"_seq - which fails
I would suggest a fix is to test each of table or column for " and if it exist then to strip it of both of table and column and encluse the whole name in "". This mighe break some old code where say the table is coded in case insensitive table name and case sensitive column key.
Sorry not much of a java programmer.
--
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, 7 months
[Hibernate-JIRA] Created: (HHH-5790) method BasicBinder#bind() slow because formatting for trace is done also with disabled trace
by Guenther Demetz (JIRA)
method BasicBinder#bind() slow because formatting for trace is done also with disabled trace
--------------------------------------------------------------------------------------------
Key: HHH-5790
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5790
Project: Hibernate Core
Issue Type: Improvement
Affects Versions: 3.6.0
Environment: 3_6_0_final
Reporter: Guenther Demetz
In the ELSE block of method org.hibernate.type.descriptor.sql.BasicBinder#bind
the if statement "if (log.isTraceEnabled())" is missing, so strings are formatted
even if trace logging is disabled.
CURRENT CODE:
if ( value == null ) {
if ( log.isTraceEnabled() ) {
log.trace(String.format(...);
}
st.setNull( index, sqlDescriptor.getSqlType() );
}
else {
log.trace(String.format(BIND_MSG_TEMPLATE,index, ...);
doBind( st, value, index, options );
}
IMPROVEMENT:
if ( value == null ) {
if ( log.isTraceEnabled() ) {
log.trace(String.format(...);
}
st.setNull( index, sqlDescriptor.getSqlType() );
}
else {
if ( log.isTraceEnabled() ) { //// NEW LINE
log.trace(String.format(BIND_MSG_TEMPLATE,index, ...);
} //// NEW LINE
doBind( st, value, index, options );
}
BTW: By doing this little code enhancement, I was able to achieve almost the double speed when inserting data.
--
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, 7 months
[Hibernate-JIRA] Created: (HHH-5025) Support caching audit queries using ehcache's DiskStore.
by Brent Worden (JIRA)
Support caching audit queries using ehcache's DiskStore.
--------------------------------------------------------
Key: HHH-5025
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5025
Project: Hibernate Core
Issue Type: Improvement
Components: envers
Reporter: Brent Worden
Priority: Minor
Enabling audit query caching with a ehcache cache configured as persisting to disk or overflowing to disk. For example,
<defaultCache diskPersistent="true" eternal="false" maxElementsInMemory="1000" maxElementsOnDisk="10000" overflowToDisk="true" timeToIdleSeconds="300" timeToLiveSeconds="3600" />
Results in the following exception:
java.io.NotSerializableException: org.hibernate.envers.entities.RevisionTypeType
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1156)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
The lack of needed serialization prohibits the use of ehcache's DiskStore.
--
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, 7 months
[Hibernate-JIRA] Created: (HHH-3325) Pagination with Oracle ROWNUM is sub-optimal
by e. wernli (JIRA)
Pagination with Oracle ROWNUM is sub-optimal
--------------------------------------------
Key: HHH-3325
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3325
Project: Hibernate3
Issue Type: Bug
Affects Versions: 3.2.5
Reporter: e. wernli
Pagination with Oracle ROWNUM is sub-optimal
The feature works but result in sub-optimal SQL. The generated SQL is the following:
select * from ( select row_.*, rownum rownum_ from ( select this_.id as id3_0_, this_.version as version3_0_, this_.name as name3_0_, this_.type as type3_0_, this_.marketstatus as marketst5_3_0_ from Customer this_ order by this_.id asc ) row_ ) where rownum_ <= ? and rownum_ > ?
But this SQL is faster:
SELECT *
FROM (SELECT row_.*, ROWNUM rownum_
FROM (SELECT this_.ID AS id3_0_, this_.VERSION AS version3_0_,
this_.NAME AS name3_0_, this_.TYPE AS type3_0_,
this_.marketstatus AS marketst5_3_0_
FROM customer this_
ORDER BY this_.ID ASC) row_
WHERE ROWNUM <= ?)
WHERE rownum_ > ?
The second solution allows Oracle to use an optimization that can dramatically reduce the time of the query, especially one of the first page is retrieved.
See this link for an explanation of this optimization: http://decipherinfosys.wordpress.com/2007/08/09/paging-and-countstopkey-o...
--
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, 7 months
[Hibernate-JIRA] Created: (HHH-4956) Native Query returns wrong results
by Akashdeep Saddi (JIRA)
Native Query returns wrong results
----------------------------------
Key: HHH-4956
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4956
Project: Hibernate Core
Issue Type: Bug
Components: query-sql
Affects Versions: 3.3.2
Environment: hibernate 3.3.2.GA , linux, oracle 10g, weblogic 10
Reporter: Akashdeep Saddi
Issue: In-case running native queries vai hibernate we have two technical ID's in the select clause from join of two or more tables the value of all the id's is set to one value.
Example
A.id = 1
B.id =2
select A.Id as A_ID, B.Id as B_ID from A, B where A.B_id = B.id will return 1,1 in the result instead of 1,2
Resolution: Use Alias in-case more than one technical keys are part of select clause. Above query works fine when changed as below
select A.Id , B.Id from A, B where A.B_id = B.id will return 1,2
--
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, 7 months
[Hibernate-JIRA] Created: (HHH-5854) ArrayIndexOutOfBounds on fetching onetoone associations using projections
by Krishna Sundaresan (JIRA)
ArrayIndexOutOfBounds on fetching onetoone associations using projections
-------------------------------------------------------------------------
Key: HHH-5854
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5854
Project: Hibernate Core
Issue Type: Bug
Components: query-criteria
Affects Versions: 3.6.0
Environment: Hibernate version 3.6.0
Reporter: Krishna Sundaresan
Attachments: testCase.zip
The loading of OneToOne associations using projections results in an ArrayIndexOutOfBounds exception when the results are loaded by the CriteriaLoader.
The stacktrace is:
{code}
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 1
at org.hibernate.loader.criteria.CriteriaLoader.getResultColumnOrRow(CriteriaLoader.java:148)
at org.hibernate.loader.Loader.getRowFromResultSet(Loader.java:639)
at org.hibernate.loader.Loader.doQuery(Loader.java:829)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:274)
at org.hibernate.loader.Loader.doList(Loader.java:2533)
at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2276)
at org.hibernate.loader.Loader.list(Loader.java:2271)
at org.hibernate.loader.criteria.CriteriaLoader.list(CriteriaLoader.java:119)
at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1716)
at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:347)
at testbed.app.HibernateApp.main(HibernateApp.java:24)
Java Result: 1
{code}
The problem seems to be with the way the association aliases and types are used in getResultRow. When the types are fetched, all the types that are mentioned in the projection clause are provided whereas when the aliases to be used are fetched SimpleProjection's getColumnCount method seems to be ignoring columns that do not span resulting in a mis-match of array indices.
{code:title=From CriteriaLoader.getResultRow(...)}
if ( translator.hasProjection() ) {
Type[] types = translator.getProjectedTypes();
result = new Object[types.length];
String[] columnAliases = translator.getProjectedColumnAliases();
...
{code}
The attached file has a test-case that will demonstrate the problem. Tested that on Hibernate 3.6.0 and derby. I was able to observe this in a case where the association is mapped by a shared primary key but I guess that same should be observable even without a shared primary key.
--
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, 7 months