[Hibernate-JIRA] Created: (HHH-3344) DB2Dialect.getLimitString doesn't work for some queries
by Damon Horrell (JIRA)
DB2Dialect.getLimitString doesn't work for some queries
-------------------------------------------------------
Key: HHH-3344
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3344
Project: Hibernate3
Issue Type: Bug
Reporter: Damon Horrell
Priority: Minor
If a query uses * but doesn't use a table alias then the modified query created by DB2Dialect.getLimitString is invalid.
e.g.
select * from mytable
becomes
select * from ( select rownumber() over() as rownumber_, * from mytable ) as temp_ where rownumber_ <= ?
which causes
DB2 SQL error: SQLCODE: -104, SQLSTATE: 42601, SQLERRMC: *;ver() as rownumber_,;<select_sublist>
I have worked around this for my project by extending DB2Dialect with:
public String getLimitString(String sql, boolean hasOffset) {
return "select * from ( select rownumber() over() as rownumber_, original_query.* from (" + sql
+ ") original_query ) as temp_ where rownumber_ <= ?";
}
This code will need extending to handle the hasOffset case etc.
Real code probably won't be using select * anyway so this probably isn't a big problem. My example allows the user to enter a custom query so I have to handle this situation.
--
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, 10 months
[Hibernate-JIRA] Created: (HHH-4943) ilike support is incomplete
by James Nobis (JIRA)
ilike support is incomplete
---------------------------
Key: HHH-4943
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4943
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.2
Environment: 3.3.2GA
MySQL/PostgreSQL
Reporter: James Nobis
ILIKE is currently supported for PostgreSQL in:
hibernate-distribution-3.3.2.GA/project/core/src/main/java/org/hibernate/criterion/IlikeExpression.java:
if ( dialect instanceof PostgreSQLDialect ) {
return columns[0] + " ilike ?";
}
else {
return dialect.getLowercaseFunction() + '(' + columns[0] + ") like ?";
}
//TODO: get SQL rendering out of this package!
1) This should be in the Dialect
2) PostgreSQL isn't the only DB with ILIKE
3) using instanceof for this is just sloppy
4) this implementation using getLowercaseFunction works with MySQL but fails with DBs like Firebird
--
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, 10 months
[Hibernate-JIRA] Created: (HHH-5969) PostgreSQLDialect missing Types.BINARY mapping, used by UUIDBinaryType
by Ondrej Zizka (JIRA)
PostgreSQLDialect missing Types.BINARY mapping, used by UUIDBinaryType
----------------------------------------------------------------------
Key: HHH-5969
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5969
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.6.2
Environment: org.hibernate.test.id.uuid.sqlrep.sqlbinary.UUIDBinaryTest.testUsage
/hudson/view/Hibernate%20Community/job/hibernate-core-testsuite-branch36/database=postgresql82,jdk=java15_default,label=hibernate/lastCompletedBuild/testReport/org.hibernate.test.id.uuid.sqlrep.sqlbinary/UUIDBinaryTest/testUsage/
Reporter: Ondrej Zizka
Assignee: Strong Liu
org.hibernate.type.UUIDBinaryType has
public int getSqlType() {
return Types.BINARY;
}
which is
java.sql.Types.BINARY = -2;
Then, org.hibernate.dialect.PostgreSQLDialect.getTypeName(-2, ...) does not have the mapping for it (only for Types.VARBINARY == -3).
org.hibernate.MappingException: No Dialect mapping for JDBC type: -2
at org.hibernate.dialect.TypeNames.get(TypeNames.java:77)
at org.hibernate.dialect.TypeNames.get(TypeNames.java:100)
at org.hibernate.dialect.Dialect.getTypeName(Dialect.java:296)
at org.hibernate.mapping.Column.getSqlType(Column.java:208)
at org.hibernate.mapping.Table.sqlTemporaryTableCreateString(Table.java:371)
at org.hibernate.mapping.PersistentClass.prepareTemporaryTables(PersistentClass.java:774)
at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:272)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1845)
at org.hibernate.testing.junit.functional.ExecutionEnvironment.initialize(ExecutionEnvironment.java:106)
at org.hibernate.testing.junit.functional.FunctionalTestCase.setUp(FunctionalTestCase.java:93)
at junit.framework.TestCase.runBare(TestCase.java:125)
at org.hibernate.testing.junit.UnitTestCase.runBare(UnitTestCase.java:63)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at sun.reflect.GeneratedMethodAccessor128.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
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:592)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
--
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, 10 months
[Hibernate-JIRA] Created: (HHH-5277) Build fails on some systems when using jdk 6
by Hardy Ferentschik (JIRA)
Build fails on some systems when using jdk 6
--------------------------------------------
Key: HHH-5277
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5277
Project: Hibernate Core
Issue Type: Bug
Components: build
Reporter: Hardy Ferentschik
When building Core using Java 6 artifacts are renamed during install from *.jar to *.jdocbook-style (at list in the core sub-module). This of course screws up the local repo. Here is the build log of a _mvn install_ in the core module:
{noformat}
517$ setJava 1.6
Configuring Shell Environment for Java 1.6
Current Java:
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02-279-10M3065)
Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01-279, mixed mode)
hardy@aleppo:~/work/hibernate/core/trunk/core
518$ mvn clean install -Dmaven.test.skip=true
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building Hibernate Core
[INFO] task-segment: [clean, install]
[INFO] ------------------------------------------------------------------------
[INFO] [clean:clean {execution: default-clean}]
[INFO] Deleting directory /Users/hardy/work/hibernate/core/trunk/core/target
[INFO] [enforcer:enforce {execution: enforce-java}]
[INFO] [antlr:generate {execution: default}]
[INFO] Using Antlr grammar: /Users/hardy/work/hibernate/core/trunk/core/src/main/antlr/hql.g
ANTLR Parser Generator Version 2.7.6 (2005-12-22) 1989-2005
warning: invalid command-line argument: -traceTreeParser; ignored
[INFO] Using Antlr grammar: /Users/hardy/work/hibernate/core/trunk/core/src/main/antlr/hql-sql.g
ANTLR Parser Generator Version 2.7.6 (2005-12-22) 1989-2005
warning: invalid command-line argument: -traceParser; ignored
[INFO] Using Antlr grammar: /Users/hardy/work/hibernate/core/trunk/core/src/main/antlr/sql-gen.g
ANTLR Parser Generator Version 2.7.6 (2005-12-22) 1989-2005
warning: invalid command-line argument: -traceParser; ignored
[INFO] Using Antlr grammar: /Users/hardy/work/hibernate/core/trunk/core/src/main/antlr/order-by.g
ANTLR Parser Generator Version 2.7.6 (2005-12-22) 1989-2005
warning: invalid command-line argument: -traceTreeParser; ignored
[INFO] Using Antlr grammar: /Users/hardy/work/hibernate/core/trunk/core/src/main/antlr/order-by-render.g
ANTLR Parser Generator Version 2.7.6 (2005-12-22) 1989-2005
warning: invalid command-line argument: -traceParser; ignored
[INFO] [resources:resources {execution: default-resources}]
[WARNING] Using platform encoding (MacRoman actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] Copying 3 resources
[INFO] Copying 5 resources
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 1306 source files to /Users/hardy/work/hibernate/core/trunk/core/target/classes
[INFO] [injection:bytecode {execution: default}]
[INFO] writing injection changes back [/Users/hardy/work/hibernate/core/trunk/core/target/classes/org/hibernate/Version.class]
[INFO] [resources:testResources {execution: default-testResources}]
[WARNING] Using platform encoding (MacRoman actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] Copying 1 resource
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] Not compiling test sources
[INFO] [surefire:test {execution: default-test}]
[INFO] Tests are skipped.
[INFO] [jar:jar {execution: default-jar}]
[INFO] Building jar: /Users/hardy/work/hibernate/core/trunk/core/target/hibernate-core-3.6.0-SNAPSHOT.jar
[INFO] [source:jar-no-fork {execution: attach-sources}]
[INFO] Building jar: /Users/hardy/work/hibernate/core/trunk/core/target/hibernate-core-3.6.0-SNAPSHOT-sources.jar
[INFO] [install:install {execution: default-install}]
[INFO] Installing /Users/hardy/work/hibernate/core/trunk/core/target/hibernate-core-3.6.0-SNAPSHOT.jar to /Users/hardy/tmp/m2/org/hibernate/hibernate-core/3.6.0-SNAPSHOT/hibernate-core-3.6.0-SNAPSHOT.jdocbook-style
[INFO] Installing /Users/hardy/work/hibernate/core/trunk/core/target/hibernate-core-3.6.0-SNAPSHOT-sources.jar to /Users/hardy/tmp/m2/org/hibernate/hibernate-core/3.6.0-SNAPSHOT/hibernate-core-3.6.0-SNAPSHOT-sources.jar
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1 minute 15 seconds
[INFO] Finished at: Fri May 28 15:29:33 CEST 2010
[INFO] Final Memory: 43M/211M
[INFO] ------------------------------------------------------------------------
{noformat}
The maven version is: _Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)_
Strong was able to reproduce the problem on his Fedora box, but on this Mac it works.
--
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, 10 months
[Hibernate-JIRA] Créée: (HHH-2389) Improving DB2 dialect
by Nicolas Billard (JIRA)
Improving DB2 dialect
---------------------
Key: HHH-2389
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2389
Project: Hibernate3
Type: Improvement
Components: query-hql
Versions: 3.2.1
Environment: Development based on v 3.2.1
Reporter: Nicolas Billard
Priority: Minor
Attachments: DB2Dialect.java
The class joined to this issue overrides the DB2 dialect. The dialect included in hibernate doesn't work very well when you want to limit returned results (when you call setFirstResult and / or setMaxResults on a query) :
- the instructions "fetch first XXX row only is not used
- a temporary table is used when it's not usefull
- when you have subselects, an exception can occur if subselects have order by clause (because of the getRowNumber method, not corrected here).
This version of getLimitString() method generates faster requests (tests made on a table of 300000 rows shows that fetching rows from 20 to 30 takes 0.3 seconds with original version, 0.02 with this one).
--
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, 10 months
[Hibernate-JIRA] Created: (HHH-5007) Using <formula> within Composite Element inside Collection
by Hepoi Ko (JIRA)
Using <formula> within Composite Element inside Collection
----------------------------------------------------------
Key: HHH-5007
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5007
Project: Hibernate Core
Issue Type: Patch
Components: core
Affects Versions: 3.5.0-CR-2
Environment: 3.5.0-CR2, AS400, Component
Reporter: Hepoi Ko
Priority: Minor
Attachments: JoinWalker.java
I was one of the user who use Hibernate in a legacy database schema, and always had a issue on using composite-key (and formula) inside collection. I was able to modify the hibernate source (from 3.3.2) to overcome such issue. I am hoping the new version 3.5.0 would even fix this problem. Anyway, I just leave the fix information here, hope it would help.
In /org/hibernate/loader/JoinWalker.java
Line 641: String[] aliasedLhsColumns = StringHelper.qualify(alias, lhsColumns);
Modify with these:
String[] fullAliasedLhsColumns = persister.getElementColumnNames(alias);
String[] aliasedLhsColumns = ArrayHelper.slice(fullAliasedLhsColumns, begin, length);
Without above change I would get NullPointerException on a mapping as
....
<set name="auditRecords" table="OEP40A" order-by="ADAT40 DESC, ATIM40 DESC"
mutable="false" inverse="true" outer-join="true">
<key>
<column name="CONO40"></column>
<column name="ORDN40"></column>
</key>
<composite-element class="com.ricoh.erp.order.domain.OrderAudit">
<property name="userId">
<column name="AUSR40"></column>
</property>
<property name="workstationId">
<column name="AWRK40"></column>
</property>
<many-to-one name="customerEntry" not-found="ignore">
<formula>CONO40</formula> <!-- NullPointerException on this line -->
<column name="CUSN40"></column>
<column name="DSEQ40"></column>
</many-to-one>
</composite-element>
With Best Regards,
--
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, 10 months
[Hibernate-JIRA] Created: (HHH-5908) unnecessary updates when using select-before-update dirty check with entity that has immutable many-to-one properties.
by Howard Kelsey (JIRA)
unnecessary updates when using select-before-update dirty check with entity that has immutable many-to-one properties.
----------------------------------------------------------------------------------------------------------------------
Key: HHH-5908
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5908
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.6.1, 3.6.0
Reporter: Howard Kelsey
Priority: Critical
Attachments: update-testcase.zip
Entities with many-to-one properties that have insert="false" update="false" are always marked as dirty! This is because when creating the sqlSnapshotSelectString in AbstractEntityPersister.getPropertyUpdateability() is used to identify which properties should be returned in that select and immutable many-to-one props are not. The AbstractEntityPersister.findModified(Object[] old, Object[] current, Object entity, SessionImplementor session) is used to work out if the object has in fact changed, however AbstractEntityPersister.propertyColumnUpdateable is always used to determine which properties are to be checked which means that immutable many-to-one properties are checked even though they're not returned by snapshot select. This is a side effect of the change made for HHH-2350 which changed ManyToOne.isAlwaysDirtyChecked to always return true. So I think it should be changed so that when comparing with the DB snapshot only the properties returned by the AbstractEntityPersister.sqlSnapshotSelectString should be checked by using AbstractEntityPersister.getPropertyUpdateability() instead of AbstractEntityPersister.propertyColumnUpdateable
--
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, 10 months