Menu
▾
▴
hibernate-issues — Hibernate JIRA Notifications
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(32) |
Jun
(175) |
Jul
(209) |
Aug
(302) |
Sep
(287) |
Oct
(339) |
Nov
(314) |
Dec
(329) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(479) |
Feb
(389) |
Mar
(599) |
Apr
(307) |
May
(390) |
Jun
(300) |
Jul
(410) |
Aug
(458) |
Sep
(299) |
Oct
(315) |
Nov
(363) |
Dec
(529) |
| 2005 |
Jan
(568) |
Feb
(434) |
Mar
(1004) |
Apr
(823) |
May
(767) |
Jun
(763) |
Jul
(854) |
Aug
(862) |
Sep
(560) |
Oct
(853) |
Nov
(763) |
Dec
(731) |
| 2006 |
Jan
(776) |
Feb
(608) |
Mar
(657) |
Apr
(424) |
May
(559) |
Jun
(440) |
Jul
(448) |
Aug
(58) |
Sep
|
Oct
(17) |
Nov
(16) |
Dec
(8) |
| 2007 |
Jan
(1) |
Feb
(8) |
Mar
(2) |
Apr
(5) |
May
(3) |
Jun
(3) |
Jul
(3) |
Aug
(16) |
Sep
(10) |
Oct
(4) |
Nov
(4) |
Dec
(4) |
| 2008 |
Jan
(8) |
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: <leg...@at...> - 2003-08-29 08:49:27
|
The following comment has been added to this issue:
Author: Max Rydahl Andersen
Created: Fri, 29 Aug 2003 3:48 AM
Body:
Please provide a patch and optimally a small test case for it!
(Then I can probably add it)
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-297
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-297
Summary: Named Parameters not recognized in 'order by' section of Query
Type: Bug
Status: Assigned
Priority: Major
Project: Hibernate2
Components:
core
Versions:
2.0.1
2.0.2
2.1 beta 1
2.1 beta 2
Assignee: Gavin King
Reporter: Roberto S. Tyley
Created: Thu, 28 Aug 2003 8:39 AM
Updated: Thu, 28 Aug 2003 3:41 PM
Environment: java.version=1.4.2
os.name=Windows 2000
Mckoi DB 1.0.2
Description:
The following query using named parameters fails:
Query q=session.createQuery("from Location loc where (loc.lonLat.UnitX between :minX and :maxX) order by ABS( loc.lonLat.UnitX - :centX )");
q.setDouble("minX", x - r);
q.setDouble("maxX", x + r);
q.setDouble("centX", x);
Iterator locs = q.iterate(); // Fails with QueryException
The final bit with 'centX' causes the problem, as the following query, with the 'centX' removed, succeeds:
Query q=session.createQuery("from Location loc where (loc.lonLat.UnitX between :minX and :maxX) order by ABS( loc.lonLat.UnitX )");
q.setDouble("minX", x - r);
q.setDouble("maxX", x + r);
Iterator locs = q.iterate(); // Succeeds
Also, using JDBC-style un-named parameters works:
Query q=session.createQuery("from Location loc where (loc.lonLat.UnitX between ? and ?) order by ABS( loc.lonLat.UnitX - ? )");
q.setDouble(0, x - r);
q.setDouble(1, x + r);
q.setDouble(2, x);
Iterator locs = q.iterate(); // Succeeds
Both of these two succeeding queries bring back all the results I would expect, with the correct ordering - so none of the function-calls or presence of a parameter in the order-by clause should be illegal.
The full stack trace is:
net.sf.hibernate.QueryException: Named parameter does not appear in Query: centX [from com.thisbedisonfire.madgag.persistence.Location loc where (loc.lonLat.UnitX between :minX and :maxX) order by ABS( loc.lonLat.UnitX - :centX )]
at net.sf.hibernate.hql.QueryTranslator.getNamedParameterLocs(QueryTranslator.java:437)
at net.sf.hibernate.hql.QueryTranslator.bindNamedParameters(QueryTranslator.java:817)
at net.sf.hibernate.loader.Loader.prepareQueryStatement(Loader.java:575)
at net.sf.hibernate.hql.QueryTranslator.iterate(QueryTranslator.java:832)
at net.sf.hibernate.impl.SessionImpl.iterate(SessionImpl.java:1436)
at net.sf.hibernate.impl.QueryImpl.iterate(QueryImpl.java:29)
at com.thisbedisonfire.madgag.Main.main(Main.java:105)
So, something's going wrong with binding of named parameters...
Hope you can help!
Roberto S. Tyley
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-08-29 08:32:27
|
The following comment has been added to this issue:
Author: Roberto S. Tyley
Created: Fri, 29 Aug 2003 3:32 AM
Body:
Cool! :-) Once I patched my copy of HB2.1beta2 last night, the named parameters queries worked fine. My patch was just to add 5 lines to OrderByParser, so the token() method is now:
public void token(String token, QueryTranslator q) throws QueryException {
if ( q.isName( StringHelper.root(token) ) ) {
ParserHelper.parse(pathExpressionParser, q.unalias(token), ParserHelper.PATH_SEPARATORS, q);
q.appendOrderByToken( pathExpressionParser.getWhereColumn() );
pathExpressionParser.addAssociation(q);
}
else if ( token.startsWith(ParserHelper.HQL_VARIABLE_PREFIX) ) { //named query parameter
q.addNamedParameter( token.substring(1) );
q.appendOrderByToken("?");
}
else {
q.appendOrderByToken(token);
}
}
Cheers,
Roberto
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-297
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-297
Summary: Named Parameters not recognized in 'order by' section of Query
Type: Bug
Status: Assigned
Priority: Major
Project: Hibernate2
Components:
core
Versions:
2.0.1
2.0.2
2.1 beta 1
2.1 beta 2
Assignee: Gavin King
Reporter: Roberto S. Tyley
Created: Thu, 28 Aug 2003 8:39 AM
Updated: Thu, 28 Aug 2003 3:41 PM
Environment: java.version=1.4.2
os.name=Windows 2000
Mckoi DB 1.0.2
Description:
The following query using named parameters fails:
Query q=session.createQuery("from Location loc where (loc.lonLat.UnitX between :minX and :maxX) order by ABS( loc.lonLat.UnitX - :centX )");
q.setDouble("minX", x - r);
q.setDouble("maxX", x + r);
q.setDouble("centX", x);
Iterator locs = q.iterate(); // Fails with QueryException
The final bit with 'centX' causes the problem, as the following query, with the 'centX' removed, succeeds:
Query q=session.createQuery("from Location loc where (loc.lonLat.UnitX between :minX and :maxX) order by ABS( loc.lonLat.UnitX )");
q.setDouble("minX", x - r);
q.setDouble("maxX", x + r);
Iterator locs = q.iterate(); // Succeeds
Also, using JDBC-style un-named parameters works:
Query q=session.createQuery("from Location loc where (loc.lonLat.UnitX between ? and ?) order by ABS( loc.lonLat.UnitX - ? )");
q.setDouble(0, x - r);
q.setDouble(1, x + r);
q.setDouble(2, x);
Iterator locs = q.iterate(); // Succeeds
Both of these two succeeding queries bring back all the results I would expect, with the correct ordering - so none of the function-calls or presence of a parameter in the order-by clause should be illegal.
The full stack trace is:
net.sf.hibernate.QueryException: Named parameter does not appear in Query: centX [from com.thisbedisonfire.madgag.persistence.Location loc where (loc.lonLat.UnitX between :minX and :maxX) order by ABS( loc.lonLat.UnitX - :centX )]
at net.sf.hibernate.hql.QueryTranslator.getNamedParameterLocs(QueryTranslator.java:437)
at net.sf.hibernate.hql.QueryTranslator.bindNamedParameters(QueryTranslator.java:817)
at net.sf.hibernate.loader.Loader.prepareQueryStatement(Loader.java:575)
at net.sf.hibernate.hql.QueryTranslator.iterate(QueryTranslator.java:832)
at net.sf.hibernate.impl.SessionImpl.iterate(SessionImpl.java:1436)
at net.sf.hibernate.impl.QueryImpl.iterate(QueryImpl.java:29)
at com.thisbedisonfire.madgag.Main.main(Main.java:105)
So, something's going wrong with binding of named parameters...
Hope you can help!
Roberto S. Tyley
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-08-28 23:35:28
|
Message:
The following issue has been re-assigned.
Assignee: Max Rydahl Andersen (mailto:xa...@xa...)
Assigner: Gavin King (mailto:ga...@in...)
Date: Thu, 28 Aug 2003 6:34 PM
Comment:
Max, would you commit this patch?
I have gone cold turkey, until the book is done.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-176
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-176
Summary: Allow for Dialect specific seperator between schema and table name
Type: Patch
Status: Assigned
Priority: Trivial
Project: Hibernate2
Components:
core
Versions:
2.0.2
Assignee: Max Rydahl Andersen
Reporter: Chris Hane
Created: Thu, 10 Jul 2003 3:02 PM
Updated: Thu, 28 Aug 2003 6:34 PM
Description:
I'm on the receiving end of a Hibernate mapping file(s) that use the schema attributes. However, I am using MySQL which does not support schema (at least with the dot notation).
I added to Dialect:
getSchemaSeperator which will supply the default seperator found in Table (StringHelper.DOT).
In MySQLDialect I overrode this function to provide StringHelper.UNDERSCORE
I modified Table to use the new attribute from Dialect in getQualifiedName()
The source I modified was the latest (2003-07-10) pulled from CVS.
Chris....
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-08-28 20:58:28
|
The following comment has been added to this issue:
Author: Mathias Bogaert
Created: Thu, 28 Aug 2003 3:56 PM
Body:
I'm not 100% sure, but 99%. I'll check again tomorrow and see if I can submit a test case to reproduce it. The strangest thing is that it works as expected using the 2.0.3 version, doing the exact same thing!
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-296
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-296
Summary: ConcurrentModificationException when initializing collection
Type: Bug
Status: Assigned
Priority: Major
Project: Hibernate2
Components:
core
Versions:
2.1
Assignee: Gavin King
Reporter: Mathias Bogaert
Created: Thu, 28 Aug 2003 6:49 AM
Updated: Thu, 28 Aug 2003 3:41 PM
Environment: 2.1 beta 2 from CVS
Description:
When initializing a collection, I get the following stacktrace (not seen with Hibernate 2.0.3):
8047 ERROR [tcpConnection-81-0] (webwork.dispatcher.ServletDispatcher:188) - Could not execute action
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.remove(HashMap.java:801)
at net.sf.hibernate.impl.SessionImpl.endLoadingCollections(SessionImpl.java:2973)
at net.sf.hibernate.loader.Loader.doResultSet(Loader.java:224)
at net.sf.hibernate.loader.Loader.doFind(Loader.java:113)
at net.sf.hibernate.loader.Loader.loadCollection(Loader.java:720)
at net.sf.hibernate.loader.Loader.loadCollection(Loader.java:703)
at net.sf.hibernate.loader.OneToManyLoader.initialize(OneToManyLoader.java:74)
at net.sf.hibernate.impl.SessionImpl.initialize(SessionImpl.java:3101)
at net.sf.hibernate.collection.PersistentCollection.forceLoad(PersistentCollection.java:236)
at net.sf.hibernate.Hibernate.initialize(Hibernate.java:255)
at com.intrasoft.persistence.hibernate.HibernatePersistenceService.initialize(HibernatePersistenceService.java:143)
at com.intrasoft.sysaudit.mission.action.wizard.AbstractMissionStepAction.initializeMission(AbstractMissionStepAction.java:112)
at com.intrasoft.sysaudit.mission.action.wizard.AbstractMissionStepAction.saveMissionInSession(AbstractMissionStepAction.java:74)
at com.intrasoft.sysaudit.mission.action.wizard.MissionStep1.doExecute(MissionStep1.java:173)
at com.opensymphony.xwork.ActionSupport.execute(ActionSupport.java:31)
Here is my code:
if (mission.getUnit() != null) {
persistenceService.initialize(mission.getUnit().getUsers());
}
and in HibernatePersistenceService:
public void initialize(Object objectToInitialize) {
try {
if (!Hibernate.isInitialized(objectToInitialize)) {
Hibernate.initialize(objectToInitialize);
}
}
catch (HibernateException e) {
throw new InfrastructureException(e);
}
}
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-08-28 20:43:28
|
Message: The following issue has been re-assigned. Assignee: Gavin King (mailto:ga...@in...) --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-295 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-295 Summary: Session.refresh leaves old data in JCS cache Type: Bug Status: Assigned Priority: Minor Project: Hibernate2 Components: core Versions: 2.0.2 Assignee: Gavin King Reporter: John Kristian Created: Wed, 27 Aug 2003 3:01 PM Updated: Thu, 28 Aug 2003 3:42 PM Environment: Windows XP, Microsoft SQL Server, JBoss 3 Description: http://sourceforge.net/forum/message.php?msg_id=2078891 Session session = sessionFactory.openSession(); Foo foo = session.load(Foo.class, id); // (1) // Now execute SQL via JDBC (not Hibernate) that changes the data from which foo is mapped. // (2) workaround: sessionFactory.evict(Foo.class, id); session.refresh(foo); // foo is copied from the database session.close(); session = sf.openSession(); Foo foo2 = session.load(Foo.class, id); // At this point, foo2 contains different data than foo. // foo2 contains the old data that foo contained at (1) above. session.close(); foo2 should contain the new data, just like foo. Ideally, session.refresh() would copy the new data into the cache. At least, it should invalidate the old cached data. One can work around this problem, by calling sessionFactory.evict at (2) above. --------------------------------------------------------------------- JIRA INFORMATION: 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.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <leg...@at...> - 2003-08-28 20:43:27
|
Message: The following issue has been re-assigned. Assignee: Gavin King (mailto:ga...@in...) --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-297 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-297 Summary: Named Parameters not recognized in 'order by' section of Query Type: Bug Status: Assigned Priority: Major Project: Hibernate2 Components: core Versions: 2.0.1 2.0.2 2.1 beta 1 2.1 beta 2 Assignee: Gavin King Reporter: Roberto S. Tyley Created: Thu, 28 Aug 2003 8:39 AM Updated: Thu, 28 Aug 2003 3:41 PM Environment: java.version=1.4.2 os.name=Windows 2000 Mckoi DB 1.0.2 Description: The following query using named parameters fails: Query q=session.createQuery("from Location loc where (loc.lonLat.UnitX between :minX and :maxX) order by ABS( loc.lonLat.UnitX - :centX )"); q.setDouble("minX", x - r); q.setDouble("maxX", x + r); q.setDouble("centX", x); Iterator locs = q.iterate(); // Fails with QueryException The final bit with 'centX' causes the problem, as the following query, with the 'centX' removed, succeeds: Query q=session.createQuery("from Location loc where (loc.lonLat.UnitX between :minX and :maxX) order by ABS( loc.lonLat.UnitX )"); q.setDouble("minX", x - r); q.setDouble("maxX", x + r); Iterator locs = q.iterate(); // Succeeds Also, using JDBC-style un-named parameters works: Query q=session.createQuery("from Location loc where (loc.lonLat.UnitX between ? and ?) order by ABS( loc.lonLat.UnitX - ? )"); q.setDouble(0, x - r); q.setDouble(1, x + r); q.setDouble(2, x); Iterator locs = q.iterate(); // Succeeds Both of these two succeeding queries bring back all the results I would expect, with the correct ordering - so none of the function-calls or presence of a parameter in the order-by clause should be illegal. The full stack trace is: net.sf.hibernate.QueryException: Named parameter does not appear in Query: centX [from com.thisbedisonfire.madgag.persistence.Location loc where (loc.lonLat.UnitX between :minX and :maxX) order by ABS( loc.lonLat.UnitX - :centX )] at net.sf.hibernate.hql.QueryTranslator.getNamedParameterLocs(QueryTranslator.java:437) at net.sf.hibernate.hql.QueryTranslator.bindNamedParameters(QueryTranslator.java:817) at net.sf.hibernate.loader.Loader.prepareQueryStatement(Loader.java:575) at net.sf.hibernate.hql.QueryTranslator.iterate(QueryTranslator.java:832) at net.sf.hibernate.impl.SessionImpl.iterate(SessionImpl.java:1436) at net.sf.hibernate.impl.QueryImpl.iterate(QueryImpl.java:29) at com.thisbedisonfire.madgag.Main.main(Main.java:105) So, something's going wrong with binding of named parameters... Hope you can help! Roberto S. Tyley --------------------------------------------------------------------- JIRA INFORMATION: 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.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <leg...@at...> - 2003-08-28 20:41:31
|
Message: The following issue has been re-assigned. Assignee: Gavin King (mailto:ga...@in...) --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-296 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-296 Summary: ConcurrentModificationException when initializing collection Type: Bug Status: Assigned Priority: Major Project: Hibernate2 Components: core Versions: 2.1 Assignee: Gavin King Reporter: Mathias Bogaert Created: Thu, 28 Aug 2003 6:49 AM Updated: Thu, 28 Aug 2003 3:41 PM Environment: 2.1 beta 2 from CVS Description: When initializing a collection, I get the following stacktrace (not seen with Hibernate 2.0.3): 8047 ERROR [tcpConnection-81-0] (webwork.dispatcher.ServletDispatcher:188) - Could not execute action java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.remove(HashMap.java:801) at net.sf.hibernate.impl.SessionImpl.endLoadingCollections(SessionImpl.java:2973) at net.sf.hibernate.loader.Loader.doResultSet(Loader.java:224) at net.sf.hibernate.loader.Loader.doFind(Loader.java:113) at net.sf.hibernate.loader.Loader.loadCollection(Loader.java:720) at net.sf.hibernate.loader.Loader.loadCollection(Loader.java:703) at net.sf.hibernate.loader.OneToManyLoader.initialize(OneToManyLoader.java:74) at net.sf.hibernate.impl.SessionImpl.initialize(SessionImpl.java:3101) at net.sf.hibernate.collection.PersistentCollection.forceLoad(PersistentCollection.java:236) at net.sf.hibernate.Hibernate.initialize(Hibernate.java:255) at com.intrasoft.persistence.hibernate.HibernatePersistenceService.initialize(HibernatePersistenceService.java:143) at com.intrasoft.sysaudit.mission.action.wizard.AbstractMissionStepAction.initializeMission(AbstractMissionStepAction.java:112) at com.intrasoft.sysaudit.mission.action.wizard.AbstractMissionStepAction.saveMissionInSession(AbstractMissionStepAction.java:74) at com.intrasoft.sysaudit.mission.action.wizard.MissionStep1.doExecute(MissionStep1.java:173) at com.opensymphony.xwork.ActionSupport.execute(ActionSupport.java:31) Here is my code: if (mission.getUnit() != null) { persistenceService.initialize(mission.getUnit().getUsers()); } and in HibernatePersistenceService: public void initialize(Object objectToInitialize) { try { if (!Hibernate.isInitialized(objectToInitialize)) { Hibernate.initialize(objectToInitialize); } } catch (HibernateException e) { throw new InfrastructureException(e); } } --------------------------------------------------------------------- JIRA INFORMATION: 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.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <leg...@at...> - 2003-08-28 20:41:30
|
Message: The following issue has been re-assigned. Assignee: Gavin King (mailto:ga...@in...) --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-293 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-293 Summary: Seperating InterBase and Firebird dialects Type: Improvement Status: Assigned Priority: Major Project: Hibernate2 Components: core Assignee: Gavin King Reporter: Reha CENANI Created: Tue, 26 Aug 2003 6:46 AM Updated: Thu, 28 Aug 2003 3:41 PM Description: At the begining, opensource Firebird (or FirebirdSQL) was based on the same source code of commercial InterBase. But during past three years, lots of improvements are done to the Firebird. Recent versions of these DBMSs have different features and statement syntaxes. For example, their select offset/limit statement syntaxes are not compatible. Hibernate's recent InterbaseDialect select limit/offset feature is based on the Firebird's select statement syntax. So, in order to prevent incompabilities and confussion, in addition to the InterbaseDialect, adding a new FirebirdDialect and seperating Firebird and InterBase features will be very helpfull. --------------------------------------------------------------------- JIRA INFORMATION: 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.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <leg...@at...> - 2003-08-28 19:45:28
|
The following comment has been added to this issue:
Author: Gavin King
Created: Thu, 28 Aug 2003 2:44 PM
Body:
whoa! Thats bad....
But I'm looking at the code and I just don't see how it could occur!
Can you please submit a main() method to reproduce this? It doesn't occur in tests and the code certainly LOOKS correct. I'm stumped!
p.s. I suppose you are _absolutely_ certain you aren't hitting the session from multiple threads....
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-296
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-296
Summary: ConcurrentModificationException when initializing collection
Type: Bug
Status: Unassigned
Priority: Major
Project: Hibernate2
Components:
core
Versions:
2.1
Assignee:
Reporter: Mathias Bogaert
Created: Thu, 28 Aug 2003 6:49 AM
Updated: Thu, 28 Aug 2003 6:49 AM
Environment: 2.1 beta 2 from CVS
Description:
When initializing a collection, I get the following stacktrace (not seen with Hibernate 2.0.3):
8047 ERROR [tcpConnection-81-0] (webwork.dispatcher.ServletDispatcher:188) - Could not execute action
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.remove(HashMap.java:801)
at net.sf.hibernate.impl.SessionImpl.endLoadingCollections(SessionImpl.java:2973)
at net.sf.hibernate.loader.Loader.doResultSet(Loader.java:224)
at net.sf.hibernate.loader.Loader.doFind(Loader.java:113)
at net.sf.hibernate.loader.Loader.loadCollection(Loader.java:720)
at net.sf.hibernate.loader.Loader.loadCollection(Loader.java:703)
at net.sf.hibernate.loader.OneToManyLoader.initialize(OneToManyLoader.java:74)
at net.sf.hibernate.impl.SessionImpl.initialize(SessionImpl.java:3101)
at net.sf.hibernate.collection.PersistentCollection.forceLoad(PersistentCollection.java:236)
at net.sf.hibernate.Hibernate.initialize(Hibernate.java:255)
at com.intrasoft.persistence.hibernate.HibernatePersistenceService.initialize(HibernatePersistenceService.java:143)
at com.intrasoft.sysaudit.mission.action.wizard.AbstractMissionStepAction.initializeMission(AbstractMissionStepAction.java:112)
at com.intrasoft.sysaudit.mission.action.wizard.AbstractMissionStepAction.saveMissionInSession(AbstractMissionStepAction.java:74)
at com.intrasoft.sysaudit.mission.action.wizard.MissionStep1.doExecute(MissionStep1.java:173)
at com.opensymphony.xwork.ActionSupport.execute(ActionSupport.java:31)
Here is my code:
if (mission.getUnit() != null) {
persistenceService.initialize(mission.getUnit().getUsers());
}
and in HibernatePersistenceService:
public void initialize(Object objectToInitialize) {
try {
if (!Hibernate.isInitialized(objectToInitialize)) {
Hibernate.initialize(objectToInitialize);
}
}
catch (HibernateException e) {
throw new InfrastructureException(e);
}
}
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-08-28 19:37:30
|
The following comment has been added to this issue:
Author: Gavin King
Created: Thu, 28 Aug 2003 2:36 PM
Body:
Thanks for tracking this down. I'm not sure if its quite a "bug", since obviously noone ever tried to implement support for parameters in the ORDER BY clause.
:)
Still, we will make this change.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-297
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-297
Summary: Named Parameters not recognized in 'order by' section of Query
Type: Bug
Status: Unassigned
Priority: Major
Project: Hibernate2
Components:
core
Versions:
2.0.1
2.0.2
2.1 beta 1
2.1 beta 2
Assignee:
Reporter: Roberto S. Tyley
Created: Thu, 28 Aug 2003 8:39 AM
Updated: Thu, 28 Aug 2003 8:39 AM
Environment: java.version=1.4.2
os.name=Windows 2000
Mckoi DB 1.0.2
Description:
The following query using named parameters fails:
Query q=session.createQuery("from Location loc where (loc.lonLat.UnitX between :minX and :maxX) order by ABS( loc.lonLat.UnitX - :centX )");
q.setDouble("minX", x - r);
q.setDouble("maxX", x + r);
q.setDouble("centX", x);
Iterator locs = q.iterate(); // Fails with QueryException
The final bit with 'centX' causes the problem, as the following query, with the 'centX' removed, succeeds:
Query q=session.createQuery("from Location loc where (loc.lonLat.UnitX between :minX and :maxX) order by ABS( loc.lonLat.UnitX )");
q.setDouble("minX", x - r);
q.setDouble("maxX", x + r);
Iterator locs = q.iterate(); // Succeeds
Also, using JDBC-style un-named parameters works:
Query q=session.createQuery("from Location loc where (loc.lonLat.UnitX between ? and ?) order by ABS( loc.lonLat.UnitX - ? )");
q.setDouble(0, x - r);
q.setDouble(1, x + r);
q.setDouble(2, x);
Iterator locs = q.iterate(); // Succeeds
Both of these two succeeding queries bring back all the results I would expect, with the correct ordering - so none of the function-calls or presence of a parameter in the order-by clause should be illegal.
The full stack trace is:
net.sf.hibernate.QueryException: Named parameter does not appear in Query: centX [from com.thisbedisonfire.madgag.persistence.Location loc where (loc.lonLat.UnitX between :minX and :maxX) order by ABS( loc.lonLat.UnitX - :centX )]
at net.sf.hibernate.hql.QueryTranslator.getNamedParameterLocs(QueryTranslator.java:437)
at net.sf.hibernate.hql.QueryTranslator.bindNamedParameters(QueryTranslator.java:817)
at net.sf.hibernate.loader.Loader.prepareQueryStatement(Loader.java:575)
at net.sf.hibernate.hql.QueryTranslator.iterate(QueryTranslator.java:832)
at net.sf.hibernate.impl.SessionImpl.iterate(SessionImpl.java:1436)
at net.sf.hibernate.impl.QueryImpl.iterate(QueryImpl.java:29)
at com.thisbedisonfire.madgag.Main.main(Main.java:105)
So, something's going wrong with binding of named parameters...
Hope you can help!
Roberto S. Tyley
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-08-28 19:33:27
|
The following comment has been added to this issue:
Author: Gavin King
Created: Thu, 28 Aug 2003 2:32 PM
Body:
Certainly you can use createSQLQuery() for this.
However, what you did with the formula attribute SHOULD have worked. Hibernate should not have aliased the function call. Can you show the _exact_ mapping you used?
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-298
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-298
Summary: Mapping of Oracle`s XMLType datatype into class
Type: Improvement
Status: Unassigned
Priority: Major
Project: Hibernate2
Versions:
2.1
Assignee:
Reporter: Marc Villeneuve
Created: Thu, 28 Aug 2003 10:34 AM
Updated: Thu, 28 Aug 2003 10:34 AM
Environment: Oracle 9ir2, patchset 9.2.0.3. and Hibernate 2.x
Description:
Hi,
There is no simple way to currently map data provided from an XMLType (xml document) into a class without rewritting a serious amount of code in EntityPersister ( please tell me if I am wrong). Extraction requires using xpath through proprietary functions (extract and extracValue).
The new formula attribute might have improve the current situation since it is now possible to call for the function, but the Oracle syntax looks more like "extractValue( alias.column, xpathExpression)" and "alias.extractValue( alias.column, xpathExpression)" as generated is invalid.
If this can be achieved otherwise (by sending a direct SQL query ?), please be nice enough to point me in the right direction.
Thanks
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-08-28 19:22:29
|
The following comment has been added to this issue:
Author: Mark Woon
Created: Thu, 28 Aug 2003 2:22 PM
Body:
Yup. It would be great if you could add that to Hibernate... ;)
I came up with the original patch for thix against the 1.x line and just don't have the time to poke under 2.x's hood to figure out something better.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-244
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-244
Summary: Hibernate creates alias identifiers that are too long
Type: Bug
Status: Unassigned
Priority: Major
Project: Hibernate2
Components:
core
Versions:
2.0.2
Assignee:
Reporter: Mark Woon
Created: Mon, 11 Aug 2003 1:17 AM
Updated: Mon, 11 Aug 2003 5:21 AM
Environment: Oracle 9.0.2.
Description:
After switching to Hibernate 2 I find that Hibernate is still creating alias identifiers that are too long.
The HQL query that's causing it:
select freqInSs, freqInRae, freqInSs.allele
from DbVariantPosition as varPos,
DbVariantAllele as varAl,
DbAlleleFrequencyInSampleSet as freqInSs,
DbAlleleFrequencyInRaceAndEthnicity as freqInRae
where varPos.goldenPathPosition = ?
and varPos.id != ?
order by freqInSs, freqInRae
The SQL query that gets generated:
select dballele2_.alleleFreqInSampleSetsId as alleleFreqInSampleSetsId0_, dballele3_.alleleFreqInSSRaceEthnicityId as alleleFreqInSSRaceEthnicityId1_, dballele2_.variantPositionId as variantP2_0_, dballele2_.sampleSetId as sampleSe3_0_, dballele2_.allele as allele0_, dballele2_.totalObserved as totalObs5_0_, dballele2_.frequency as frequency0_, dballele3_.alleleFreqInSampleSetId as alleleFr2_1_, dballele3_.racialClassId as racialCl3_1_, dballele3_.ethnicClassId as ethnicCl4_1_, dballele3_.totalObserved as totalObs5_1_, dballele3_.frequency as frequency1_, dballele2_.alleleFreqInSampleSetsId as x0_0_, dballele3_.alleleFreqInSSRaceEthnicityId as x1_0_, dballele2_.allele as x2_0_ from VariantPositions dbvarian0_, VariantAlleles dbvarian1_, AlleleFreqInSampleSets dballele2_, AlleleFreqInSSRaceEthnicity dballele3_ where (dbvarian0_.goldenPathPosition=? )and(dbvarian0_.variantPositionId!=? ) order by dballele2_.alleleFreqInSampleSetsId , dballele3_.alleleFreqInSSRaceEthnicityId
The offending alias identifier is "alleleFreqInSSRaceEthnicityId1_" which is 31 characters long -- one more that Oracle's max identifier length.
Is this a known problem? I can attach my mappings if it will help...
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-08-28 16:29:30
|
The following comment has been added to this issue:
Author: Roberto S. Tyley
Created: Thu, 28 Aug 2003 11:28 AM
Body:
Having had a look through the HB 2.1beta2 sources, I've found the apparent reason for this behaviour. The job of converting named parameters is being handled correctly by net.sf.hibernate.hql.WhereParser, while net.sf.hibernate.hql.OrderByParser is not performing this binding step.
'WhereParser' is substantially more complicated than 'OrderByParser' (465 lines vs 46!), but the code critical to this bug seems to be only 5 lines long, some code in the doToken() method at line 365 in WhereParser.java would do the job if pasted into the token() method around line 30 in OrderByParser.java. The code in WhereParser is:
---------------
if ( q.isName( StringHelper.root(token) ) ) { //path expression
doPathExpression( q.unalias(token), q);
}
else if ( token.startsWith(ParserHelper.HQL_VARIABLE_PREFIX) ) { //named query parameter
q.addNamedParameter( token.substring(1) );
appendToken(q, "?");
}
else {
... lalalala, lots of code here ...
---------------
The code in OrderByParser is currently:
------------------
if ( q.isName( StringHelper.root(token) ) ) {
ParserHelper.parse(pathExpressionParser, q.unalias(token), ParserHelper.PATH_SEPARATORS, q);
q.appendOrderByToken( pathExpressionParser.getWhereColumn() );
pathExpressionParser.addAssociation(q);
}
else {
q.appendOrderByToken(token);
}
-------------------
You can see that both pieces of code do the 'isName' test, but then OrderBy omits to do the test to see if the token starts with ParserHelper.HQL_VARIABLE_PREFIX (which has the value ':', of course!). Adding that test and the appropriate code to OrderByParser would fix my problem, though some kind of refactoring of WhereParser, OrderByParser, and the other Parser classes so that they can use common code might be a better solution .
Incidentally, the hibernate source code can be a bit confusing regarding this issue. There are several variables and methods in net.sf.hibernate.impl.AbstractQueryImpl which might appear to do this job of named parameter binding, but which in fact do nothing at all unless you've used the setParameterList() method on Query - that is to say, you're binding lists of values, and not single values using methods like setDouble(), as I do in my example.
Cheers,
Roberto
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-297
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-297
Summary: Named Parameters not recognized in 'order by' section of Query
Type: Bug
Status: Unassigned
Priority: Major
Project: Hibernate2
Components:
core
Versions:
2.0.1
2.0.2
2.1 beta 1
2.1 beta 2
Assignee:
Reporter: Roberto S. Tyley
Created: Thu, 28 Aug 2003 8:39 AM
Updated: Thu, 28 Aug 2003 8:39 AM
Environment: java.version=1.4.2
os.name=Windows 2000
Mckoi DB 1.0.2
Description:
The following query using named parameters fails:
Query q=session.createQuery("from Location loc where (loc.lonLat.UnitX between :minX and :maxX) order by ABS( loc.lonLat.UnitX - :centX )");
q.setDouble("minX", x - r);
q.setDouble("maxX", x + r);
q.setDouble("centX", x);
Iterator locs = q.iterate(); // Fails with QueryException
The final bit with 'centX' causes the problem, as the following query, with the 'centX' removed, succeeds:
Query q=session.createQuery("from Location loc where (loc.lonLat.UnitX between :minX and :maxX) order by ABS( loc.lonLat.UnitX )");
q.setDouble("minX", x - r);
q.setDouble("maxX", x + r);
Iterator locs = q.iterate(); // Succeeds
Also, using JDBC-style un-named parameters works:
Query q=session.createQuery("from Location loc where (loc.lonLat.UnitX between ? and ?) order by ABS( loc.lonLat.UnitX - ? )");
q.setDouble(0, x - r);
q.setDouble(1, x + r);
q.setDouble(2, x);
Iterator locs = q.iterate(); // Succeeds
Both of these two succeeding queries bring back all the results I would expect, with the correct ordering - so none of the function-calls or presence of a parameter in the order-by clause should be illegal.
The full stack trace is:
net.sf.hibernate.QueryException: Named parameter does not appear in Query: centX [from com.thisbedisonfire.madgag.persistence.Location loc where (loc.lonLat.UnitX between :minX and :maxX) order by ABS( loc.lonLat.UnitX - :centX )]
at net.sf.hibernate.hql.QueryTranslator.getNamedParameterLocs(QueryTranslator.java:437)
at net.sf.hibernate.hql.QueryTranslator.bindNamedParameters(QueryTranslator.java:817)
at net.sf.hibernate.loader.Loader.prepareQueryStatement(Loader.java:575)
at net.sf.hibernate.hql.QueryTranslator.iterate(QueryTranslator.java:832)
at net.sf.hibernate.impl.SessionImpl.iterate(SessionImpl.java:1436)
at net.sf.hibernate.impl.QueryImpl.iterate(QueryImpl.java:29)
at com.thisbedisonfire.madgag.Main.main(Main.java:105)
So, something's going wrong with binding of named parameters...
Hope you can help!
Roberto S. Tyley
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-08-28 15:34:27
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-298 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-298 Summary: Mapping of Oracle`s XMLType datatype into class Type: Improvement Status: Unassigned Priority: Major Project: Hibernate2 Versions: 2.1 Assignee: Reporter: Marc Villeneuve Created: Thu, 28 Aug 2003 10:34 AM Updated: Thu, 28 Aug 2003 10:34 AM Environment: Oracle 9ir2, patchset 9.2.0.3. and Hibernate 2.x Description: Hi, There is no simple way to currently map data provided from an XMLType (xml document) into a class without rewritting a serious amount of code in EntityPersister ( please tell me if I am wrong). Extraction requires using xpath through proprietary functions (extract and extracValue). The new formula attribute might have improve the current situation since it is now possible to call for the function, but the Oracle syntax looks more like "extractValue( alias.column, xpathExpression)" and "alias.extractValue( alias.column, xpathExpression)" as generated is invalid. If this can be achieved otherwise (by sending a direct SQL query ?), please be nice enough to point me in the right direction. Thanks --------------------------------------------------------------------- JIRA INFORMATION: 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.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <leg...@at...> - 2003-08-28 13:48:33
|
The following comment has been added to this issue:
Author: Roberto S. Tyley
Created: Thu, 28 Aug 2003 8:46 AM
Body:
Sorry, I should have added in the environment section that the stack trace is actually from Hibernate 2.1beta2 - although the code still fails on all the other mentioned versions of Hibernate!
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-297
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-297
Summary: Named Parameters not recognized in 'order by' section of Query
Type: Bug
Status: Unassigned
Priority: Major
Project: Hibernate2
Components:
core
Versions:
2.0.1
2.0.2
2.1 beta 1
2.1 beta 2
Assignee:
Reporter: Roberto S. Tyley
Created: Thu, 28 Aug 2003 8:39 AM
Updated: Thu, 28 Aug 2003 8:39 AM
Environment: java.version=1.4.2
os.name=Windows 2000
Mckoi DB 1.0.2
Description:
The following query using named parameters fails:
Query q=session.createQuery("from Location loc where (loc.lonLat.UnitX between :minX and :maxX) order by ABS( loc.lonLat.UnitX - :centX )");
q.setDouble("minX", x - r);
q.setDouble("maxX", x + r);
q.setDouble("centX", x);
Iterator locs = q.iterate(); // Fails with QueryException
The final bit with 'centX' causes the problem, as the following query, with the 'centX' removed, succeeds:
Query q=session.createQuery("from Location loc where (loc.lonLat.UnitX between :minX and :maxX) order by ABS( loc.lonLat.UnitX )");
q.setDouble("minX", x - r);
q.setDouble("maxX", x + r);
Iterator locs = q.iterate(); // Succeeds
Also, using JDBC-style un-named parameters works:
Query q=session.createQuery("from Location loc where (loc.lonLat.UnitX between ? and ?) order by ABS( loc.lonLat.UnitX - ? )");
q.setDouble(0, x - r);
q.setDouble(1, x + r);
q.setDouble(2, x);
Iterator locs = q.iterate(); // Succeeds
Both of these two succeeding queries bring back all the results I would expect, with the correct ordering - so none of the function-calls or presence of a parameter in the order-by clause should be illegal.
The full stack trace is:
net.sf.hibernate.QueryException: Named parameter does not appear in Query: centX [from com.thisbedisonfire.madgag.persistence.Location loc where (loc.lonLat.UnitX between :minX and :maxX) order by ABS( loc.lonLat.UnitX - :centX )]
at net.sf.hibernate.hql.QueryTranslator.getNamedParameterLocs(QueryTranslator.java:437)
at net.sf.hibernate.hql.QueryTranslator.bindNamedParameters(QueryTranslator.java:817)
at net.sf.hibernate.loader.Loader.prepareQueryStatement(Loader.java:575)
at net.sf.hibernate.hql.QueryTranslator.iterate(QueryTranslator.java:832)
at net.sf.hibernate.impl.SessionImpl.iterate(SessionImpl.java:1436)
at net.sf.hibernate.impl.QueryImpl.iterate(QueryImpl.java:29)
at com.thisbedisonfire.madgag.Main.main(Main.java:105)
So, something's going wrong with binding of named parameters...
Hope you can help!
Roberto S. Tyley
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-08-28 13:39:27
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-297 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-297 Summary: Named Parameters not recognized in 'order by' section of Query Type: Bug Status: Unassigned Priority: Major Project: Hibernate2 Components: core Versions: 2.0.1 2.0.2 2.1 beta 1 2.1 beta 2 Assignee: Reporter: Roberto S. Tyley Created: Thu, 28 Aug 2003 8:39 AM Updated: Thu, 28 Aug 2003 8:39 AM Environment: java.version=1.4.2 os.name=Windows 2000 Mckoi DB 1.0.2 Description: The following query using named parameters fails: Query q=session.createQuery("from Location loc where (loc.lonLat.UnitX between :minX and :maxX) order by ABS( loc.lonLat.UnitX - :centX )"); q.setDouble("minX", x - r); q.setDouble("maxX", x + r); q.setDouble("centX", x); Iterator locs = q.iterate(); // Fails with QueryException The final bit with 'centX' causes the problem, as the following query, with the 'centX' removed, succeeds: Query q=session.createQuery("from Location loc where (loc.lonLat.UnitX between :minX and :maxX) order by ABS( loc.lonLat.UnitX )"); q.setDouble("minX", x - r); q.setDouble("maxX", x + r); Iterator locs = q.iterate(); // Succeeds Also, using JDBC-style un-named parameters works: Query q=session.createQuery("from Location loc where (loc.lonLat.UnitX between ? and ?) order by ABS( loc.lonLat.UnitX - ? )"); q.setDouble(0, x - r); q.setDouble(1, x + r); q.setDouble(2, x); Iterator locs = q.iterate(); // Succeeds Both of these two succeeding queries bring back all the results I would expect, with the correct ordering - so none of the function-calls or presence of a parameter in the order-by clause should be illegal. The full stack trace is: net.sf.hibernate.QueryException: Named parameter does not appear in Query: centX [from com.thisbedisonfire.madgag.persistence.Location loc where (loc.lonLat.UnitX between :minX and :maxX) order by ABS( loc.lonLat.UnitX - :centX )] at net.sf.hibernate.hql.QueryTranslator.getNamedParameterLocs(QueryTranslator.java:437) at net.sf.hibernate.hql.QueryTranslator.bindNamedParameters(QueryTranslator.java:817) at net.sf.hibernate.loader.Loader.prepareQueryStatement(Loader.java:575) at net.sf.hibernate.hql.QueryTranslator.iterate(QueryTranslator.java:832) at net.sf.hibernate.impl.SessionImpl.iterate(SessionImpl.java:1436) at net.sf.hibernate.impl.QueryImpl.iterate(QueryImpl.java:29) at com.thisbedisonfire.madgag.Main.main(Main.java:105) So, something's going wrong with binding of named parameters... Hope you can help! Roberto S. Tyley --------------------------------------------------------------------- JIRA INFORMATION: 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.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <leg...@at...> - 2003-08-28 12:39:27
|
The following issue has been updated:
Updater: Dylan Etkin (mailto:de...@cs...)
Date: Thu, 28 Aug 2003 7:38 AM
Comment:
This has been updated to be more efficient for table metadata lookups. I have put in commented out code that will speed up the initSequeneces method iff hibernate only ever cares about sequences named "hibernate_sequence". I haven't looked at the code enough to know if this is so.
Changes:
Attachment changed to schemaUpdate.patch
---------------------------------------------------------------------
For a full history of the issue, see:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-278&page=history
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-278
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-278
Summary: calling Configuration.generateSchemaUpdateScript always generates create sql
Type: Patch
Status: Unassigned
Priority: Major
Project: Hibernate2
Components:
core
Versions:
2.1
Assignee:
Reporter: Dylan Etkin
Created: Thu, 21 Aug 2003 7:23 AM
Updated: Thu, 28 Aug 2003 7:38 AM
Environment: postgres, oracle, mysql
Description:
The call to generateSchemaUpdateScript was always creating the create sql when running in postgres. The problem was with the case of the table name and an uppercase version being sent as a parameter to the DatabaseMetaData. The sequences were also always comming back as in need of a create since none of the dialects implement the getQuerySequencesString method. The fk's were not matching on their hashed name since the metaData name had more info than just the display name. I have fixed these issues and tested it on postgres, oracle, and mysql. It seems to work for me so I am submitting the patch. I am by-passing the call to getQuerySequencesString and just using the metaData to get all sequences if they exist.
There is an outstanding issue with mysql where the call to getIndexIterator in the Table class returns an empty iterator so the index create statements are always generated. I have not looked into this.
Hope this helps.
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-08-28 11:49:27
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-296 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-296 Summary: ConcurrentModificationException when initializing collection Type: Bug Status: Unassigned Priority: Major Project: Hibernate2 Components: core Versions: 2.1 Assignee: Reporter: Mathias Bogaert Created: Thu, 28 Aug 2003 6:49 AM Updated: Thu, 28 Aug 2003 6:49 AM Environment: 2.1 beta 2 from CVS Description: When initializing a collection, I get the following stacktrace (not seen with Hibernate 2.0.3): 8047 ERROR [tcpConnection-81-0] (webwork.dispatcher.ServletDispatcher:188) - Could not execute action java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.remove(HashMap.java:801) at net.sf.hibernate.impl.SessionImpl.endLoadingCollections(SessionImpl.java:2973) at net.sf.hibernate.loader.Loader.doResultSet(Loader.java:224) at net.sf.hibernate.loader.Loader.doFind(Loader.java:113) at net.sf.hibernate.loader.Loader.loadCollection(Loader.java:720) at net.sf.hibernate.loader.Loader.loadCollection(Loader.java:703) at net.sf.hibernate.loader.OneToManyLoader.initialize(OneToManyLoader.java:74) at net.sf.hibernate.impl.SessionImpl.initialize(SessionImpl.java:3101) at net.sf.hibernate.collection.PersistentCollection.forceLoad(PersistentCollection.java:236) at net.sf.hibernate.Hibernate.initialize(Hibernate.java:255) at com.intrasoft.persistence.hibernate.HibernatePersistenceService.initialize(HibernatePersistenceService.java:143) at com.intrasoft.sysaudit.mission.action.wizard.AbstractMissionStepAction.initializeMission(AbstractMissionStepAction.java:112) at com.intrasoft.sysaudit.mission.action.wizard.AbstractMissionStepAction.saveMissionInSession(AbstractMissionStepAction.java:74) at com.intrasoft.sysaudit.mission.action.wizard.MissionStep1.doExecute(MissionStep1.java:173) at com.opensymphony.xwork.ActionSupport.execute(ActionSupport.java:31) Here is my code: if (mission.getUnit() != null) { persistenceService.initialize(mission.getUnit().getUsers()); } and in HibernatePersistenceService: public void initialize(Object objectToInitialize) { try { if (!Hibernate.isInitialized(objectToInitialize)) { Hibernate.initialize(objectToInitialize); } } catch (HibernateException e) { throw new InfrastructureException(e); } } --------------------------------------------------------------------- JIRA INFORMATION: 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.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <leg...@at...> - 2003-08-28 10:28:27
|
The following comment has been added to this issue:
Author: Gavin King
Created: Thu, 28 Aug 2003 5:28 AM
Body:
Thanks.
This should be very easy to fix in a patch.
The fix would look something like calling:
cache.lock(object)
from SessionImpl.refresh() just *before* reloading, then
cache.update( object, new CacheEntry(...) );
just *after* reloading.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-295
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-295
Summary: Session.refresh leaves old data in JCS cache
Type: Bug
Status: Unassigned
Priority: Minor
Project: Hibernate2
Components:
core
Versions:
2.0.2
Assignee:
Reporter: John Kristian
Created: Wed, 27 Aug 2003 3:01 PM
Updated: Wed, 27 Aug 2003 3:01 PM
Environment: Windows XP, Microsoft SQL Server, JBoss 3
Description:
http://sourceforge.net/forum/message.php?msg_id=2078891
Session session = sessionFactory.openSession();
Foo foo = session.load(Foo.class, id); // (1)
// Now execute SQL via JDBC (not Hibernate) that changes the data from which foo is mapped.
// (2) workaround: sessionFactory.evict(Foo.class, id);
session.refresh(foo); // foo is copied from the database
session.close();
session = sf.openSession();
Foo foo2 = session.load(Foo.class, id);
// At this point, foo2 contains different data than foo.
// foo2 contains the old data that foo contained at (1) above.
session.close();
foo2 should contain the new data, just like foo. Ideally, session.refresh() would copy the new data into the cache. At least, it should invalidate the old cached data.
One can work around this problem, by calling sessionFactory.evict at (2) above.
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-08-28 07:45:29
|
The following comment has been added to this issue:
Author: Kevin Yeung
Created: Thu, 28 Aug 2003 2:44 AM
Body:
Hi Mark. I realised that after I posted my previous comment. Come to think of it, another way would be to change the way aliases are generated altogether. There is no reason why we must use the format <original_table_name> + <number> + <underscore>. For example, we can use simply T0, T1, T2, T3... With a length of 30, this would give us up to 10^29 aliases without breaching the database limitation. Even a length of 5 gives us 10k aliases.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-244
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-244
Summary: Hibernate creates alias identifiers that are too long
Type: Bug
Status: Unassigned
Priority: Major
Project: Hibernate2
Components:
core
Versions:
2.0.2
Assignee:
Reporter: Mark Woon
Created: Mon, 11 Aug 2003 1:17 AM
Updated: Mon, 11 Aug 2003 5:21 AM
Environment: Oracle 9.0.2.
Description:
After switching to Hibernate 2 I find that Hibernate is still creating alias identifiers that are too long.
The HQL query that's causing it:
select freqInSs, freqInRae, freqInSs.allele
from DbVariantPosition as varPos,
DbVariantAllele as varAl,
DbAlleleFrequencyInSampleSet as freqInSs,
DbAlleleFrequencyInRaceAndEthnicity as freqInRae
where varPos.goldenPathPosition = ?
and varPos.id != ?
order by freqInSs, freqInRae
The SQL query that gets generated:
select dballele2_.alleleFreqInSampleSetsId as alleleFreqInSampleSetsId0_, dballele3_.alleleFreqInSSRaceEthnicityId as alleleFreqInSSRaceEthnicityId1_, dballele2_.variantPositionId as variantP2_0_, dballele2_.sampleSetId as sampleSe3_0_, dballele2_.allele as allele0_, dballele2_.totalObserved as totalObs5_0_, dballele2_.frequency as frequency0_, dballele3_.alleleFreqInSampleSetId as alleleFr2_1_, dballele3_.racialClassId as racialCl3_1_, dballele3_.ethnicClassId as ethnicCl4_1_, dballele3_.totalObserved as totalObs5_1_, dballele3_.frequency as frequency1_, dballele2_.alleleFreqInSampleSetsId as x0_0_, dballele3_.alleleFreqInSSRaceEthnicityId as x1_0_, dballele2_.allele as x2_0_ from VariantPositions dbvarian0_, VariantAlleles dbvarian1_, AlleleFreqInSampleSets dballele2_, AlleleFreqInSSRaceEthnicity dballele3_ where (dbvarian0_.goldenPathPosition=? )and(dbvarian0_.variantPositionId!=? ) order by dballele2_.alleleFreqInSampleSetsId , dballele3_.alleleFreqInSSRaceEthnicityId
The offending alias identifier is "alleleFreqInSSRaceEthnicityId1_" which is 31 characters long -- one more that Oracle's max identifier length.
Is this a known problem? I can attach my mappings if it will help...
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-08-28 07:32:29
|
The following comment has been added to this issue:
Author: Mark Woon
Created: Thu, 28 Aug 2003 2:32 AM
Body:
Kevin, I don't think that will work because the tables/columns could have similar names (e.g. Table1 and Table2). If you just truncate to an arbitrary length, the different names could get truncated to the same thing. So with a max length of 5, you'd get the two tables with the name "Table".
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-244
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-244
Summary: Hibernate creates alias identifiers that are too long
Type: Bug
Status: Unassigned
Priority: Major
Project: Hibernate2
Components:
core
Versions:
2.0.2
Assignee:
Reporter: Mark Woon
Created: Mon, 11 Aug 2003 1:17 AM
Updated: Mon, 11 Aug 2003 5:21 AM
Environment: Oracle 9.0.2.
Description:
After switching to Hibernate 2 I find that Hibernate is still creating alias identifiers that are too long.
The HQL query that's causing it:
select freqInSs, freqInRae, freqInSs.allele
from DbVariantPosition as varPos,
DbVariantAllele as varAl,
DbAlleleFrequencyInSampleSet as freqInSs,
DbAlleleFrequencyInRaceAndEthnicity as freqInRae
where varPos.goldenPathPosition = ?
and varPos.id != ?
order by freqInSs, freqInRae
The SQL query that gets generated:
select dballele2_.alleleFreqInSampleSetsId as alleleFreqInSampleSetsId0_, dballele3_.alleleFreqInSSRaceEthnicityId as alleleFreqInSSRaceEthnicityId1_, dballele2_.variantPositionId as variantP2_0_, dballele2_.sampleSetId as sampleSe3_0_, dballele2_.allele as allele0_, dballele2_.totalObserved as totalObs5_0_, dballele2_.frequency as frequency0_, dballele3_.alleleFreqInSampleSetId as alleleFr2_1_, dballele3_.racialClassId as racialCl3_1_, dballele3_.ethnicClassId as ethnicCl4_1_, dballele3_.totalObserved as totalObs5_1_, dballele3_.frequency as frequency1_, dballele2_.alleleFreqInSampleSetsId as x0_0_, dballele3_.alleleFreqInSSRaceEthnicityId as x1_0_, dballele2_.allele as x2_0_ from VariantPositions dbvarian0_, VariantAlleles dbvarian1_, AlleleFreqInSampleSets dballele2_, AlleleFreqInSSRaceEthnicity dballele3_ where (dbvarian0_.goldenPathPosition=? )and(dbvarian0_.variantPositionId!=? ) order by dballele2_.alleleFreqInSampleSetsId , dballele3_.alleleFreqInSSRaceEthnicityId
The offending alias identifier is "alleleFreqInSSRaceEthnicityId1_" which is 31 characters long -- one more that Oracle's max identifier length.
Is this a known problem? I can attach my mappings if it will help...
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-08-27 20:10:28
|
The following comment has been added to this issue:
Author: John Kristian
Created: Wed, 27 Aug 2003 3:09 PM
Body:
Here's a log excerpt from a similar case, which I hope will help.
2003-08-27 12:21:35,312 DEBUG [net.sf.hibernate.impl.SessionImpl] refreshing [com.docent.lms.entities.reference.ReferenceLearningActivity#49]
2003-08-27 12:21:35,312 DEBUG [net.sf.hibernate.persister.EntityPersister] Materializing entity: com.docent.lms.entities.reference.ReferenceLearningActivity#49
...
2003-08-27 12:21:35,312 DEBUG [net.sf.hibernate.loader.Loader] Initializing object from ResultSet: 49
2003-08-27 12:21:35,312 DEBUG [net.sf.hibernate.loader.Loader] Hydrating entity: com.docent.lms.entities.reference.ReferenceLearningActivity#49
...
2003-08-27 12:21:35,312 DEBUG [net.sf.hibernate.loader.Loader] total objects hydrated: 1
2003-08-27 12:21:35,312 DEBUG [net.sf.hibernate.impl.SessionImpl] resolving associations for [com.docent.lms.entities.reference.ReferenceLearningActivity#49]
...
2003-08-27 12:21:35,312 DEBUG [net.sf.hibernate.impl.SessionImpl] adding entity to JCS cache [com.docent.lms.entities.reference.ReferenceLearningActivity#49]
2003-08-27 12:21:35,312 DEBUG [net.sf.hibernate.cache.ReadWriteCache] Caching: 49
2003-08-27 12:21:35,312 DEBUG [net.sf.hibernate.cache.ReadWriteCache] Could not cache net.sf.hibernate.impl.CacheEntry#49; CachedItem is fresh
2003-08-27 12:21:35,312 DEBUG [net.sf.hibernate.impl.SessionImpl] done materializing entity [com.docent.lms.entities.reference.ReferenceLearningActivity#49]
To obtain this log, I modified src/net/sf/hibernate/cache/ReadWriteCache.java thus:
@@ -66,7 +66,19 @@
return true;
}
else {
- if ( log.isTraceEnabled() ) log.trace("Could not cache: " + key);
+ if (log.isTraceEnabled()) {
+ StringBuffer msg = new StringBuffer();
+ msg.append("Could not cache: ").append(key);
+ if ( ! item.isUnlocked())
+ msg.append("; CachedItem is locked");
+ if (item.isFresh())
+ msg.append("; CachedItem is fresh");
+ if (item.getUnlockTimestamp() >= txTimestamp)
+ msg.append("; CachedItem.unlockTimestamp ").append(item.getUnlockTimestamp())
+ .append(" >= ").append(txTimestamp)
+ ;
+ log.trace(msg.toString());
+ }
return false;
}
}
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-295
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-295
Summary: Session.refresh leaves old data in JCS cache
Type: Bug
Status: Unassigned
Priority: Minor
Project: Hibernate2
Components:
core
Versions:
2.0.2
Assignee:
Reporter: John Kristian
Created: Wed, 27 Aug 2003 3:01 PM
Updated: Wed, 27 Aug 2003 3:01 PM
Environment: Windows XP, Microsoft SQL Server, JBoss 3
Description:
http://sourceforge.net/forum/message.php?msg_id=2078891
Session session = sessionFactory.openSession();
Foo foo = session.load(Foo.class, id); // (1)
// Now execute SQL via JDBC (not Hibernate) that changes the data from which foo is mapped.
// (2) workaround: sessionFactory.evict(Foo.class, id);
session.refresh(foo); // foo is copied from the database
session.close();
session = sf.openSession();
Foo foo2 = session.load(Foo.class, id);
// At this point, foo2 contains different data than foo.
// foo2 contains the old data that foo contained at (1) above.
session.close();
foo2 should contain the new data, just like foo. Ideally, session.refresh() would copy the new data into the cache. At least, it should invalidate the old cached data.
One can work around this problem, by calling sessionFactory.evict at (2) above.
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-08-27 20:02:27
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-295 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-295 Summary: Session.refresh leaves old data in JCS cache Type: Bug Status: Unassigned Priority: Minor Project: Hibernate2 Components: core Versions: 2.0.2 Assignee: Reporter: John Kristian Created: Wed, 27 Aug 2003 3:01 PM Updated: Wed, 27 Aug 2003 3:01 PM Environment: Windows XP, Microsoft SQL Server, JBoss 3 Description: http://sourceforge.net/forum/message.php?msg_id=2078891 Session session = sessionFactory.openSession(); Foo foo = session.load(Foo.class, id); // (1) // Now execute SQL via JDBC (not Hibernate) that changes the data from which foo is mapped. // (2) workaround: sessionFactory.evict(Foo.class, id); session.refresh(foo); // foo is copied from the database session.close(); session = sf.openSession(); Foo foo2 = session.load(Foo.class, id); // At this point, foo2 contains different data than foo. // foo2 contains the old data that foo contained at (1) above. session.close(); foo2 should contain the new data, just like foo. Ideally, session.refresh() would copy the new data into the cache. At least, it should invalidate the old cached data. One can work around this problem, by calling sessionFactory.evict at (2) above. --------------------------------------------------------------------- JIRA INFORMATION: 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.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <leg...@at...> - 2003-08-27 14:27:27
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-294 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-294 Summary: Precompilation of Hibernate mappings (e.g. serialized Configuration/SessionFactory) Type: New Feature Status: Unassigned Priority: Major Project: Hibernate2 Components: core toolset Versions: 2.1 beta 2 Assignee: Reporter: Aksel Hilde Created: Wed, 27 Aug 2003 9:26 AM Updated: Wed, 27 Aug 2003 9:26 AM Environment: - Description: To use Hibernate at run-time one must first load and "compile" all the mapping files. Something like this: Configuration config = ...; //Load all properties and mapping files SessionFactory sessionFactory = config.buildSessionFactory(); This is very nice when the domain model change rapidly, because things are always up to date when unit testing. But when the domain model is relatively stable, this "compilation" takes quite some time. It would therefore be very nice to have a tool to "pre-compile" all the mappings and store them in a file in serialized form, and the ability to create a SessionFactory or at least a Configuration at run-time by loading the pre-compiled mappings. This would speed up unit testing a lot for us!! We have a J2SE-client + J2EE-server app, but are doing all our business logic unit testing in a single VM. So when I would like to run a jUnit test, then the time taken to compile mappings is relatively high compared to the time the actual test takes. And now we only have about 20 entities, pretty soon that number will double or tripple. Anyway, thanks for a great O/R tool!! Best regards Aksel Hilde --------------------------------------------------------------------- JIRA INFORMATION: 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.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <leg...@at...> - 2003-08-27 10:38:29
|
The following comment has been added to this issue:
Author: Reha CENANI
Created: Wed, 27 Aug 2003 5:37 AM
Body:
Regarding the For Update [Of] issues:
*** Common ***
supportsForUpdate() --> true
supportsForUpdateOf() --> true
supportsForUpdateNowait() --> false
*** For Firebird: ***
SELECT ... [FOR UPDATE [OF col [, col ...]]] [WITH LOCK]]
About optional [WITH LOCK]:
Firebird is an optimistic-locking system. The need for a pessimistic lock in Firebird is very rare indeed.
The addition of the optional WITH LOCK clause provides a limited explicit pessimistic locking capability for cautious use in conditions where the affected row set is a) extremely small (ideally, a singleton) and b) precisely controlled by the application code.
If the WITH LOCK clause succeeds, it will secure a lock on the selected rows and prevent any other transaction from obtaining write access to any of those rows, or their dependents, until your transaction ends.
If the FOR UPDATE clause is included, the lock will be applied to each row, one by one, as it is fetched into the server-side row cache. It becomes possible, then, that a lock which appeared to succeed when requested will nevertheless fail subsequently, when an attempt is made to fetch a row which becomes locked by another transaction.
The SELECT... WITH LOCK construct can succeed only in a top-level,
single-table SELECT statement. It is not available in a subquery specification, nor for joined sets. It cannot be specified with the DISTINCT operator, a GROUP BY clause or any other aggregating operation. It cannot be used in or with a view, nor with an external table, nor with the output of a selectable stored procedure.
*** For InterBase: ***
SELECT ... [FOR UPDATE [OF col [, col ...]]]
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-293
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-293
Summary: Seperating InterBase and Firebird dialects
Type: Improvement
Status: Unassigned
Priority: Major
Project: Hibernate2
Components:
core
Assignee:
Reporter: Reha CENANI
Created: Tue, 26 Aug 2003 6:46 AM
Updated: Tue, 26 Aug 2003 6:46 AM
Description:
At the begining, opensource Firebird (or FirebirdSQL) was based on the same source code of commercial InterBase. But during past three years, lots of improvements are done to the Firebird. Recent versions of these DBMSs have different features and statement syntaxes.
For example, their select offset/limit statement syntaxes are not compatible. Hibernate's recent InterbaseDialect select limit/offset feature is based on the Firebird's select statement syntax.
So, in order to prevent incompabilities and confussion, in addition to the InterbaseDialect, adding a new FirebirdDialect and seperating Firebird and InterBase features will be very helpfull.
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
93 messages has been excluded from this view by a project administrator.
