[Hibernate-JIRA] Created: (HHH-3938) One-To-One Filter Applied, Non-Lazy Fetch Problem
by Sandeep Vaid (JIRA)
One-To-One Filter Applied, Non-Lazy Fetch Problem
-------------------------------------------------
Key: HHH-3938
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3938
Project: Hibernate Core
Issue Type: Improvement
Components: core
Affects Versions: 3.3.1
Reporter: Sandeep Vaid
Priority: Critical
Suppose i have one-to-one association between Product and ProductBasic. and we have applied filter on ProductBasic Class.
I have applied this filter as in Java side we have one-to-one relationship between Product and ProductBasic BUT at database side
we have one-to-many relationship between PRODUCT and PRODUCTBASIC. and we apply a condition (STARTTIME < CURRETTIME < ENDTIME)
while fetching PRODUCTBASIC, and this will always give me one record out of many.
So i have put this condition as filter in ProductBasic class.
In current hibernate, one-to-one associations are always non-lazily fetched. Moreover it doesn't apply filter conditions.
I understand that it can;t apply filter condition as some filter parameter must be provided at runtime and
user may not provide them (as he is not asking for ProductBasic)... Also in this case, proper proxy can't be created as
until we apply the filter criteria, we won't get one ProductBasic row (among many)..
I think hibernate code should be changed so that if a filter is declared on the associated class (ProductBasic in our case),
hibernate should return null for ProductBasic.
--
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-3828) Criteria: Restriction whith class does not work
by Kai Prünte (JIRA)
Criteria: Restriction whith class does not work
-----------------------------------------------
Key: HHH-3828
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3828
Project: Hibernate Core
Issue Type: Bug
Components: query-criteria
Affects Versions: 3.3.1
Environment: Oracle, HSQLDB
Reporter: Kai Prünte
The following line does not work:
Restrictions.eq("class", Bike.class)
because
SingleTableEntityPersister.getDiscriminatorSQLValue()
returns the discriminator value quoted with single quotes. However JDBC needs the string without quotes.
Workaround:
Restrictions.eq("class", Bike.class.getName())
This works fine for the default discriminator values
Patch in CriteriaQueryTranslator.getTypedValue(Criteria subcriteria, String propertyName, Object value):
if(stringValue != null && stringValue.length() > 2 && stringValue.startsWith("'") && stringValue.endsWith("'") ) {
// remove the single quotes
stringValue = stringValue.substring(1, stringValue.length() - 1);
}
--
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-4529) Support for derived identity (including @MapsId)
by Emmanuel Bernard (JIRA)
Support for derived identity (including @MapsId)
------------------------------------------------
Key: HHH-4529
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4529
Project: Hibernate Core
Issue Type: Sub-task
Components: annotations
Reporter: Emmanuel Bernard
Fix For: 3.5
2.4.1.1
IdClass (derived side)
"The names of the attributes of the id class and the Id attributes of the dependent entity class
must correspond as follows:
• The Id attribute in the entity class and the corresponding attribute in the id class must
have the same name.
• If an Id attribute in the entity class is of basic type, the corresponding attribute in the
id class must have the same type.
• If an Id attribute in the entity is a many-to-one or one-to-one relationship to a parent
entity, the corresponding attribute in the id class must be of the same Java type as the
id class or embedded id of the parent entity (if the parent entity has a composite pri-
mary key) or the type of the Id attribute of the parent entity (if the parent entity has a
simple primary key). "
This basically mean that property names int he entity and idClass must match. Types should be identical unless a @Id @XToOne Parent parent; is present in the entity. In this case the corresponding IdClass property should be of the type of the Parent PK
"Alternatively, If the dependent entity has a single primary key attribute (i.e., the relationship attribute), the id
class specified by the dependent entity must be the same as the primary key class of the parent
entity. The Id annotation is applied to the relationship to the parent entity."
"If the dependent entity uses an embedded id to represent its primary key, the attribute in the embedded
id corresponding to the relationship attribute must be of the same type as the primary key of the parent
entity and must be designated by the MapsId annotation applied to the relationship attribute. The
value element of the MapsId annotation must be used to specify the name of the attribute within the
embedded id to which the relationship attribute corresponds. If the embedded id of the dependent entity
is of the same Java type as the primary key of the parent entity, the relationship attribute maps both the
relationship to the parent and the primary key of the dependent entity, and in this case the MapsId
annotation is specified without the value element."
class Person
@Id PersonPK id;
@MapsId("ssnId") @ManyToOne SSN ssn;
static class PersonPK {
String name;
String ssnId;
}
}
class SSN {
@Id String id;
}
"If the dependent entity has a single primary key attribute (i.e, the relationship attribute or an attribute
that corresponds to the relationship attribute) and the primary key of the parent entity is a simple pri-
mary key, the primary key of the dependent entity is a simple primary key of the same type as that of the
parent entity (and neither EmbeddedId nor IdClass is specified). In this case, either (1) the rela-
tionship attribute is annotated Id, or (2) a separate Id attribute is specified and the relationship attribute
is annotated MapsId (and the value element of the MapsId annotation is not specified)"
"A primary key attribute that is derived from the identity of a parent entity is mapped by the correspond-
ing relationship attribute. The default mapping for this relationship is as specified in section 2.10. In
the case where a default mapping does not apply or where a default mapping is to be overridden, the
JoinColumn or JoinColumns annotation is used on the relationship attribute.
If the dependent entity uses an embedded id to represent its primary key, the AttributeOverride
annotation may be used to override the default mapping of embedded id attributes that do not corre-
spond to the relationship attributes mapping the derived identity. The embedded id attributes that cor-
respond to the relationship are treated by the provider as "read only"—that is, any updates to them on
the part of the application are not propagated to the database.
If the dependent uses an id class, the Column annotation may be used to override the default mapping
of Id attributes that are not relationship attributes. "
Examples for all that on page 31
--
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-2501) Read-only state of an entity in a session to propagate into subsequently lazy-loaded entities.
by Gunther Schadow (JIRA)
Read-only state of an entity in a session to propagate into subsequently lazy-loaded entities.
----------------------------------------------------------------------------------------------
Key: HHH-2501
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2501
Project: Hibernate3
Type: Improvement
Components: core
Environment: any
Reporter: Gunther Schadow
ISSUE:
Given an Entity entity and after Session.setReadOnly(entity), if the entity has lazy collections, lazy properties etc., other Entities are loaded into the Session upon navigating the object graph in the default read-writable state. However, it seems more reasonable to maintain the read-only state of the owning object.
REQUEST:
Ability to propagate read-only state of an entity in a session into other lazy-loaded entities.
BACKGROUND:
We have a system which permits users to make concurrent transactions which involve many of the same objects. Usually no changes happen on these shared objects, but instead connections (links) are made between these objects and new objects. For example, say you have an online meeting system, and every Meeting held has a link to a number of User object. The User objects are never changed in a Meeting, but there is a Relation called Participation (of User in Meeting) to which new relationships are added. When a new meeting is saved, it wants to save the User objects simply because a new Participation link entry was added to the collection.
To an extent we can prevent this from happening by setting the Users explicitly to read-only. However, now suppose we added a function "Invite your Friends" to a Meeting, in which we would simply go:
for(User friend : currentUser.getFriends())
meeting.addInvitation(friend);
Now an Invitation is like a Participation, and would be added into the User but now it wants to save these users just for a version upgrade only because they have received an Invitation.
--
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: (HBX-1074) DelegatingReverseEngineeringStratey.columnToHibernateTypeName reports invalid values
by Joel Schuster (JIRA)
DelegatingReverseEngineeringStratey.columnToHibernateTypeName reports invalid values
------------------------------------------------------------------------------------
Key: HBX-1074
URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-1074
Project: Hibernate Tools
Issue Type: Improvement
Components: reverse-engineer
Affects Versions: 3.2.1
Environment: MyEclipse w/ Hibernate rev engineering against Oracle 10g
Reporter: Joel Schuster
When implementing an extention to the [u]DelegatingReverseEngineeringStrategy [/u]the [u]columnToHibernateTypeName [/u]does not report the true value of the [b]precision [/b]and [b]scale [/b]column of the table description/definition.
The method signature:
[code]@Override
public String columnToHibernateTypeName( TableIdentifier table, String columnName, int sqlType,
int length, int precision, int scale, boolean nullable,
boolean generatedIdentifier) {[/code]
The precision and scale parameters are [b]int[/b]. If the values in the definition are [b]null[/b] the values reported here come out as DATA_LENGTH and 0. Not null.
These parameters should be [b]Integer[/b] and be set to [b]null [/b]when applicable.
--
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-4068) Hibernate's ReadWriteCache synchronization slow down ehcache
by shaoxian yang (JIRA)
Hibernate's ReadWriteCache synchronization slow down ehcache
-------------------------------------------------------------
Key: HHH-4068
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4068
Project: Hibernate Core
Issue Type: Bug
Reporter: shaoxian yang
Hi, I am setting up hibernate to work with ehcache. Hibernate has a wrapper to call underlying ehcache.
Their wrappers are ReadWriteCache.java, which internally will call Ehcache. The two major methods in ReadWriteCache are synchronized:
public synchronized Object get(Object key, long txTimestamp) throws CacheException {
public synchronized boolean put(
Object key,
Object value,
long txTimestamp,
Object version,
Comparator versionComparator,
boolean minimalPut)
I understand this is to ensure "read/write" strategy to read committed (when write and read thread get in at the same time, read does not get intermediate result and only get the latest committed result).
However, isn't this also make concurrent read impossible when there is no write? ).
It looks like we need some more advanced read/write lock at ReadWriteCache level. However, the class also have other synchronized methods which make me hesitate:
public synchronized SoftLock lock(Object key, Object version) throws CacheException
public synchronized void release(Object key, SoftLock clientLock) throws CacheException
public synchronized boolean afterUpdate(Object key, Object value, Object version, SoftLock clientLock)
throws CacheException
public synchronized boolean afterInsert(Object key, Object value, Object version)
throws CacheException
public synchronized SoftLock lock(Object key, Object version) throws CacheException
Basically I want to get the most out of ehcache performance gain. Currently, if I keep issuing the same query which read item from query cache, there is still overhead.
Can you advise me why we have to use read lock for every read when there is no write? And is it necessary to acquire lock for any other operation than put/get in ReadWriteCache class?
Thanks in advance.
--
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-4455) Changes are not properly rollbacked after a bulk operation involving classes that use joined-subclass mapping
by dilbert (JIRA)
Changes are not properly rollbacked after a bulk operation involving classes that use joined-subclass mapping
-------------------------------------------------------------------------------------------------------------
Key: HHH-4455
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4455
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 3.3.0.SP1, 3.2.5
Environment: Hibernate 3.2.5.ga and 3.3.0.SP1
MySql database version 5.1.36
Driver : mysql-connector-java-5.1.6
Reporter: dilbert
Attachments: TransactionTest.zip
I have a Location class on which two other classes "depend" (Contact and LocationTransaction).
When I want to delete a Location Object I use bulk update operations. First I delete the LocationTransactions
connected to the Location object and then I delete the contact objects connected to the location object. Finally
I delete the Location object itself. At the end I simulate that something went wrong and trigger a Rollback.
After the rollback I would expect that none of the objects that I tried to delete was actually deleted. However,
all the LocationTransaction objects are missing from the database after the rollback. Since the other objects
are rollbacked properly I figure that the problem is connected to the fact that LocationTransactions is inherited
from Transaction and uses joined-subclass mapping which is included in the test project in the attachment.
private static void doTest() {
final Session s = sf.openSession();
final Transaction tx = s.beginTransaction();
try {
Location l = (Location) s.createQuery("from Location l where l.name = 'l1'").uniqueResult();
final Query deleteTransactionQuery = s.createQuery(
"delete from LocationTransaction lt " +
"where lt.location = (:location)");
deleteTransactionQuery.setParameter("location", l);
deleteTransactionQuery.executeUpdate();
final Query deleteContactQuery = s.createQuery(
"delete from Contact c " +
"where c.location = (:location)");
deleteContactQuery.setParameter("location", l);
deleteContactQuery.executeUpdate();
final Query deleteQuery = s.createQuery(
"delete from Location l where l = (:location)");
deleteQuery.setParameter("location", l);
deleteQuery.executeUpdate();
//s.delete(l);
throw new RuntimeException("test");
//tx.commit();
} catch (Exception e) {
tx.rollback();
System.out.println(e);
} finally {
s.close();
}
}
Please contact me with any further questions.
Thanks for the help.
--
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-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-3338) Order of attributes in generated SQL query is dependent on Java version
by Michael Gerz (JIRA)
Order of attributes in generated SQL query is dependent on Java version
-----------------------------------------------------------------------
Key: HHH-3338
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3338
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.6
Environment: WIndows XP, Java 5 Update 15, Java 6 update 5
Reporter: Michael Gerz
We use Hibernate Core 3.2.6 in combination with Derby 10.4.1.3.
When migrating from Java 5 to Java 6, we noticed a huge performance hit. Our analysis has unveiled that Hibernate 3.2.6 produces semantical identical but syntactically different queries for Java 5 and Java 6.
Java 5:
Hibernate: select logevent0_.ID as ID7_, logevent0_.INDEX_SENT as INDEX2_7_, logevent0_.TEST_RUN_ID as TEST3_7_, logevent0_.SENDER as SENDER7_, logevent0_.TIME_SENT as TIME5_7_, logevent0_.MESSAGE as MESSAGE8_, logevent0_.SEVERITY as SEVERITY8_, logevent0_.SERIALIZED_CONTENT as SERIALIZED1_11_, logevent0_.RECEIVER as RECEIVER11_, logevent0_.TIME_RECEIVED as TIME3_11_, logevent0_.INDEX_RECEIVED as INDEX4_11_, logevent0_.ACTION_REQUEST as ACTION1_13_, logevent0_.ACTION_REPLY as ACTION1_14_, logevent0_.clazz_ as clazz_ from ( select TEST_RUN_ID, SENDER, MESSAGE, SEVERITY, nullif('x','x') as SERIALIZED_CONTENT, nullif('2000-1-1 00:00:00','2000-1-1 00:00:00') as TIME_RECEIVED, ID, nullif('x','x') as ACTION_REQUEST, TIME_SENT, nullif('x','x') as ACTION_REPLY, nullif('x','x') as RECEIVER, nullif(0,0) as INDEX_RECEIVED, INDEX_SENT, 2 as clazz_ from USER_LOG_EVENT union all select TEST_RUN_ID, SENDER, MESSAGE, SEVERITY, nullif('x','x') as SERIALIZED_CONTENT, nullif('2000-1-1 00:00:00','2000-1-1 00:00:00') as TIME_RECEIVED, ID, nullif('x','x') as ACTION_REQUEST, TIME_SENT, nullif('x','x') as ACTION_REPLY, nullif('x','x') as RECEIVER, nullif(0,0) as INDEX_RECEIVED, INDEX_SENT, 3 as clazz_ from DEVEL_LOG_EVENT union all select TEST_RUN_ID, SENDER, nullif('x','x') as MESSAGE, nullif('x','x') as SEVERITY, nullif('x','x') as SERIALIZED_CONTENT, nullif('2000-1-1 00:00:00','2000-1-1 00:00:00') as TIME_RECEIVED, ID, ACTION_REQUEST, TIME_SENT, nullif('x','x') as ACTION_REPLY, nullif('x','x') as RECEIVER, nullif(0,0) as INDEX_RECEIVED, INDEX_SENT, 6 as clazz_ from ACTION_REQUEST_LOG_EVENT union all select TEST_RUN_ID, SENDER, nullif('x','x') as MESSAGE, nullif('x','x') as SEVERITY, nullif('x','x') as SERIALIZED_CONTENT, nullif('2000-1-1 00:00:00','2000-1-1 00:00:00') as TIME_RECEIVED, ID, nullif('x','x') as ACTION_REQUEST, TIME_SENT, ACTION_REPLY, nullif('x','x') as RECEIVER, nullif(0,0) as INDEX_RECEIVED, INDEX_SENT, 7 as clazz_ from ACTION_REPLY_LOG_EVENT union all select TEST_RUN_ID, SENDER, nullif('x','x') as MESSAGE, nullif('x','x') as SEVERITY, SERIALIZED_CONTENT, TIME_RECEIVED, ID, nullif('x','x') as ACTION_REQUEST, TIME_SENT, nullif('x','x') as ACTION_REPLY, RECEIVER, INDEX_RECEIVED, INDEX_SENT, 4 as clazz_ from DATA_FLOW_LOG_EVENT ) logevent0_ where logevent0_.TEST_RUN_ID=?
Java 6:
Hibernate: select logevent0_.ID as ID7_, logevent0_.INDEX_SENT as INDEX2_7_, logevent0_.TEST_RUN_ID as TEST3_7_, logevent0_.SENDER as SENDER7_, logevent0_.TIME_SENT as TIME5_7_, logevent0_.MESSAGE as MESSAGE8_, logevent0_.SEVERITY as SEVERITY8_, logevent0_.SERIALIZED_CONTENT as SERIALIZED1_11_, logevent0_.RECEIVER as RECEIVER11_, logevent0_.TIME_RECEIVED as TIME3_11_, logevent0_.INDEX_RECEIVED as INDEX4_11_, logevent0_.ACTION_REQUEST as ACTION1_13_, logevent0_.ACTION_REPLY as ACTION1_14_, logevent0_.clazz_ as clazz_ from ( select nullif('x','x') as RECEIVER, TIME_SENT, SEVERITY, nullif('2000-1-1 00:00:00','2000-1-1 00:00:00') as TIME_RECEIVED, ID, SENDER, MESSAGE, TEST_RUN_ID, nullif('x','x') as SERIALIZED_CONTENT, INDEX_SENT, nullif(0,0) as INDEX_RECEIVED, nullif('x','x') as ACTION_REQUEST, nullif('x','x') as ACTION_REPLY, 2 as clazz_ from USER_LOG_EVENT union all select nullif('x','x') as RECEIVER, TIME_SENT, SEVERITY, nullif('2000-1-1 00:00:00','2000-1-1 00:00:00') as TIME_RECEIVED, ID, SENDER, MESSAGE, TEST_RUN_ID, nullif('x','x') as SERIALIZED_CONTENT, INDEX_SENT, nullif(0,0) as INDEX_RECEIVED, nullif('x','x') as ACTION_REQUEST, nullif('x','x') as ACTION_REPLY, 3 as clazz_ from DEVEL_LOG_EVENT union all select nullif('x','x') as RECEIVER, TIME_SENT, nullif('x','x') as SEVERITY, nullif('2000-1-1 00:00:00','2000-1-1 00:00:00') as TIME_RECEIVED, ID, SENDER, nullif('x','x') as MESSAGE, TEST_RUN_ID, nullif('x','x') as SERIALIZED_CONTENT, INDEX_SENT, nullif(0,0) as INDEX_RECEIVED, ACTION_REQUEST, nullif('x','x') as ACTION_REPLY, 6 as clazz_ from ACTION_REQUEST_LOG_EVENT union all select nullif('x','x') as RECEIVER, TIME_SENT, nullif('x','x') as SEVERITY, nullif('2000-1-1 00:00:00','2000-1-1 00:00:00') as TIME_RECEIVED, ID, SENDER, nullif('x','x') as MESSAGE, TEST_RUN_ID, nullif('x','x') as SERIALIZED_CONTENT, INDEX_SENT, nullif(0,0) as INDEX_RECEIVED, nullif('x','x') as ACTION_REQUEST, ACTION_REPLY, 7 as clazz_ from ACTION_REPLY_LOG_EVENT union all select RECEIVER, TIME_SENT, nullif('x','x') as SEVERITY, TIME_RECEIVED, ID, SENDER, nullif('x','x') as MESSAGE, TEST_RUN_ID, SERIALIZED_CONTENT, INDEX_SENT, INDEX_RECEIVED, nullif('x','x') as ACTION_REQUEST, nullif('x','x') as ACTION_REPLY, 4 as clazz_ from DATA_FLOW_LOG_EVENT ) logevent0_ where logevent0_.TEST_RUN_ID=?
The first order (using Java 5) looks more reasonable, because TEST_RUN_ID is the first column in all of the tables and it is also a foreign key.
The changed order of attributes does not really explain why Derby performs so poor on Java 6 and we have already issued a report to the Derby community.
Nevertheless, the SQL queries generated Hibernate should not depend on a specific version of Java. Maybe a compareTo() method is missing somewhere in the code...?
--
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