November 2006 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Updated: (HHH-1851) "special" identifier property in HQL unnecessaryily causing problems

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1851?page=all ] Steve Ebersole updated HHH-1851: -------------------------------- Fix Version: 3.2.2 Assign To: Steve Ebersole > "special" identifier property in HQL unnecessaryily causing problems > -------------------------------------------------------------------- > > Key: HHH-1851 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1851 > Project: Hibernate3 > Type: Improvement > Components: query-hql > Versions: 3.0 alpha, 3.0 beta 1, 3.0 beta 2, 3.0 beta 3, 3.0 beta 4, 3.0 rc 1, 3.0 final, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, 3.1 beta 1, 3.1 beta 2, 3.1 rc 1, 3.1 rc2, 3.1 rc3, 3.1, 3.1.1, 3.1.2, 3.1.3 > Environment: independent, all versions all databases. > Reporter: Gunther Schadow > Assignee: Steve Ebersole > Fix For: 3.2.2 > > Original Estimate: 1 hour > Remaining: 1 hour > > I HAVE REPORTED THIS PROBLEM BEFORE IN HHH-1127. THEN IT WAS FLAGGED AS "DUPLICATE" AND CLOSED PLEASE TELL ME WHAT IS THE ID OF THE REPORT WHICH THIS SUPPOSEDLY DUPLICATES? > When a user decides to use the name "id" as the name of a property, HQL queries break with unspecific exceptions, because HQL assumes "id" as reserved for the Hibernate id attribute defined in the hbm file using the <id .../> tag. This is bad design in our view, because it puts an unnecessary constraint and interference with the otherwise transparent "object persistence for idiomatic Java." > For example, a mapping file may contain: > <class name="MyObject"> > <id name="internalId" ... /> > <property name="id" .../> > <property name="foo" .../> > </class> > And since even the <id .../> element has a @name property, why can't HQL use that name rather than shadowing a perfectly good identifier for a normal property? > The HQL query > from MyObject where id='123' > and this would fail because 'id' in HQL means the 'internalId' property not the property called 'id'. But if I wanted to access the internalId I could just as well have sayd: > from MyObject where internalId='123' > I do not understand the value of this feature and it is causing us tremendous problems, because our object property names are fixed by some larger standards body and I can't just replace "id" with some other name just because of HQL! > I am currently hacking every version of Hibernate by changing only one line in > org.hibernate.persister.entity.EntityPersister > from > public static final String ENTITY_ID = "id"; > to > public static final String ENTITY_ID = "hid"; > But that of course is a problem and also breaking it for anyone who uses "hid" as a normal property name. > I really don't understand what the value of this feature is and I am asking you to drop it alltogether or turn it into some really weird name or some function, whatever, but this "special" id attribute really, really hurts. > Please, if you close this issue again, at least comment about your rationale or link it with the bug where it had been discussed. Thank you! -- 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

19 years, 1 month

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-2130) SQLQuery does not autoflush all entities used in the query

by Frank Tolstrup (JIRA)

SQLQuery does not autoflush all entities used in the query ---------------------------------------------------------- Key: HHH-2130 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2130 Project: Hibernate3 Type: Bug Components: query-sql, core Versions: 3.1.3 Environment: Hibernate version 3.1.3, Oracle v 9.2 Reporter: Frank Tolstrup I have a problem with autoflushing on native SQL queries. The scenario is: 1. I use a complex sql with a lot of joined tables 2. I change some of the associated objects from the result (but not the returned types). 3. I do the same sql as in step 1 The problem is that the autoflush before the sql in step 3 only flushes changes in objects of the class returned by the sql, NOT all other objects used in the query. If I change the query in step 3 to HQL it works as I would expect and flushes all objects included in the query. It says in the hibernate documentation (section 10.10 Flushing the session), that "However, Hibernate does guarantee that the Query.list(..) will never return stale data; nor will they return the wrong data." This seems not to be the case with native SQL queries. The SQL query: (flushes only changed Tjeneste objects) SQLQuery sqlQuery = session.createSQLQuery ("SELECT /*+ use_nl(a av) */ {t.*}" +"FROM TJENESTE t, " +"TJENESTEVERSION tv, " +"ALLOKERING a, " +"ALLOKERINGSVERSION av " +"WHERE t.TJENESTE_ID = tv.TJENESTE_ID " +"AND av.plan_id = 0 " +"AND av.slettet = 0 " +"AND av.allokering_id = a.allokering_id " +"AND a.medarbejder_id =:medarb " +"AND tv.tjeneste_id = av.tjeneste_id " +"AND tv.fra_tid >= :fraTid " +"AND tv.til_tid <= :tilTid" ); The HQL query: (flushes changed objects of classes Tjeneste, TjenesteVersion, AllokeringsVersion, Allokering) ("SELECT av.tjeneste " +" FROM" +" TjenesteVersion tv," +" AllokeringsVersion av" +" WHERE " +" av.plan.id = 0" +" and av.slettet = 0" +" and av.allokering.medarbejder.id = :medarb" +" and tv.tjeneste = av.tjeneste" +" and tv.plan.id = 0" +" and tv.fraTid >= :fraTid" +" and tv.tilTid <= :tilTid" It would be enough to add a method to SQLQuery to add entities to the QuerySpace that will be flushed before the query is executed. An api method to match the "<synchronize>" in a named query. Regards, Frank PS: See the thread in the Hibernate user forum: http://forum.hibernate.org/viewtopic.php?p=2324846 -- 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

19 years, 1 month

5
7
0 / 0

[Hibernate-JIRA] Created: (HBX-827) New projects given a console configuration don't persist before the workbench exits (or crashes)

by Max Rydahl Andersen (JIRA)

New projects given a console configuration don't persist before the workbench exits (or crashes) ------------------------------------------------------------------------------------------------ Key: HBX-827 URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-827 Project: Hibernate Tools Type: Improvement Versions: 3.2beta8 Reporter: Max Rydahl Andersen Fix For: 3.2beta9 http://jira.jboss.com/jira/browse/JBIDE-391 -- 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

19 years, 1 month

1
1
0 / 0

[Hibernate-JIRA] Commented: (HHH-1889) LockMode.UPGRADE does not work for get(), load() and refresh() on SQL Server

by Steve Finch (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1889?page=c... ] Steve Finch commented on HHH-1889: ---------------------------------- I've tested the AbstractEntityJoinWalker suggestion and it does in fact fix the SQL Server issue. I suggest that the fix go in and that the HQL bug report be broken out into a separate issue so that this one can be closed in the build. > LockMode.UPGRADE does not work for get(), load() and refresh() on SQL Server > ---------------------------------------------------------------------------- > > Key: HHH-1889 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1889 > Project: Hibernate3 > Type: Bug > Components: core > Versions: 3.2.0.cr2, 3.2.0.cr3 > Environment: Windows XP, Hibernate 3.2.cr3 > Reporter: Matthias Germann > Priority: Critical > > > Passing a LockMode parameter to the get(), load() or refresh() method of the Session class has no effect on MS SQL Server. > The statement > session.load(ProcessInstance.class, 33l, LockMode.UPGRADE) > produces this SQL Statement with the SQLServerDialect: > select > processins0_.ID_ as ID1_20_0_, > processins0_.VERSION_ as VERSION2_20_0_, > processins0_.START_ as START3_20_0_, > processins0_.END_ as END4_20_0_, > processins0_.ISSUSPENDED_ as ISSUSPEN5_20_0_, > processins0_.PROCESSDEFINITION_ as PROCESSD6_20_0_, > processins0_.ROOTTOKEN_ as ROOTTOKEN7_20_0_, > processins0_.SUPERPROCESSTOKEN_ as SUPERPRO8_20_0_ > from > JBPM_PROCESSINSTANCE processins0_ > where > processins0_.ID_=? > This Statement does not contain the requested locking hint. The FROM claus should look like this: > from JBPM_PROCESSINSTANCE processins0_ with (updlock, rowlock) > The OracleDialect produces a correct statement with a FOR UPDATE clause > select > processins0_.ID_ as ID1_20_0_, > processins0_.VERSION_ as VERSION2_20_0_, > processins0_.START_ as START3_20_0_, > processins0_.END_ as END4_20_0_, > processins0_.ISSUSPENDED_ as ISSUSPEN5_20_0_, > processins0_.PROCESSDEFINITION_ as PROCESSD6_20_0_, > processins0_.ROOTTOKEN_ as ROOTTOKEN7_20_0_, > processins0_.SUPERPROCESSTOKEN_ as SUPERPRO8_20_0_ > from > JBPM_PROCESSINSTANCE processins0_ > where > processins0_.ID_=? for update > The lock() method works correctly. > IMHO, the problem is that only the SimpleSelect class uses the appendLockHint() method of the Dialect class. The Select class does not seam to use the appendLockHint() method. -- 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

19 years, 1 month

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-2245) Resetting of properties after initial set violates constraints we want to protect

by Jim Showalter (JIRA)

Resetting of properties after initial set violates constraints we want to protect --------------------------------------------------------------------------------- Key: HHH-2245 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2245 Project: Hibernate3 Type: Improvement Versions: 3.1.2 Environment: Windows XP with all service packs and patches. Reporter: Jim Showalter We have properties on objects that are supposed to be set only once, when first reading an object back from the database. Once in memory, they are not supposed to be set again, and attempting to do so is supposed to throw an exception. Unfortunately, hibernate's behavior appears to be less predictable than we had thought. It assigns properties more than once. For example, when merging a disconnected object, it loads one from the database (thus setting the properties), and then sets them again from the other object, thus violating the set-once rule. There are other cases similar to this. We modified our rule to allow setting to null (or some other value indicating not-yet-set) as many times as desired, then setting to some actual value, and allowing setting to that same value as many times as desired. Setting to a different value once set throws an exception. This seems to pacify hibernate, but we're not certain that it will work in all cases, and the behavior of hibernate as far as resetting properties is concerned is undefined. Our request is for hibernate to be enhanced to have a notion of set-once, which would be stated in the HBM file. This would make a property immutable, with the sole setting of that property to be done on reading in from the database. On save, a set-once property would be assumed to have already been set--hibernate would not set it itself when saving, only when reading. -- 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

19 years, 1 month

3
6
0 / 0

[Hibernate-JIRA] Created: (HHH-2252) Fix for HHH-2208 rebuilds Settings for each table mapping

by Alex Burgel (JIRA)

Fix for HHH-2208 rebuilds Settings for each table mapping --------------------------------------------------------- Key: HHH-2252 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2252 Project: Hibernate3 Type: Improvement Components: core Versions: 3.2.0.ga Environment: Hibernate 2.1 beta 4, Oracle 8i Reporter: Alex Burgel Fix For: 3.2.1 When using SchemaUpdate, the DatabaseMetaData.getTableMetadata() looks for a table with the correct table name in any database schema and it take the first one it found. This behavior is uncorrect if I have a table existing in different schemas. The correct behavior would be to first look in the schema with the login name and after in any schema. user1.article user2.article I connected whith user2, DatabaseMetaData should first look for user2.article, then if not found to %.article. Adrien -- 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

19 years, 1 month

2
4
0 / 0

[Hibernate-JIRA] Created: (HHH-2251) Settings build unnecessary in schemaupdate/schemavalidate

by Max Rydahl Andersen (JIRA)

Settings build unnecessary in schemaupdate/schemavalidate --------------------------------------------------------- Key: HHH-2251 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2251 Project: Hibernate3 Type: Bug Versions: 3.2.1 Reporter: Max Rydahl Andersen Priority: Critical Fix For: 3.2.2 stupid regression bug -- 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

19 years, 1 month

1
2
0 / 0

[Hibernate-JIRA] Commented: (HHH-2208) Table schema use in DatabaseMetadata

by Max Rydahl Andersen (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2208?page=c... ] Max Rydahl Andersen commented on HHH-2208: ------------------------------------------ arh crap! > Table schema use in DatabaseMetadata > ------------------------------------ > > Key: HHH-2208 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2208 > Project: Hibernate3 > Type: Improvement > Components: core > Versions: 3.2.0.ga > Environment: Hibernate 2.1 beta 4, Oracle 8i > Reporter: Adrien > Fix For: 3.2.1 > Attachments: DatabaseMetadata.java, HB-534_patch.txt, TableMetadata.java, patch.txt, patch1.1.txt, patch1.2.txt, schemavalidation.zip > > > When using SchemaUpdate, the DatabaseMetaData.getTableMetadata() looks for a table with the correct table name in any database schema and it take the first one it found. This behavior is uncorrect if I have a table existing in different schemas. > The correct behavior would be to first look in the schema with the login name and after in any schema. > user1.article > user2.article > I connected whith user2, DatabaseMetaData should first look for user2.article, then if not found to %.article. > Adrien -- 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

19 years, 1 month

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-2208) Table schema use in DatabaseMetadata

by Alex Burgel (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2208?page=c... ] Alex Burgel commented on HHH-2208: ---------------------------------- the fix for this bug causes a new Settings object to be built for each table mapping when doing a schema update or validate. this is unnecessary. in some scenarios, it might be expensive to build a new settings object because it communicates with the database for metadata and it also creates a cache provider, which might be expensive to create for clustered caches. to fix, buildSettings (lines 947 and 1069) should be pulled out of the while loop. > Table schema use in DatabaseMetadata > ------------------------------------ > > Key: HHH-2208 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2208 > Project: Hibernate3 > Type: Improvement > Components: core > Versions: 3.2.0.ga > Environment: Hibernate 2.1 beta 4, Oracle 8i > Reporter: Adrien > Fix For: 3.2.1 > Attachments: DatabaseMetadata.java, HB-534_patch.txt, TableMetadata.java, patch.txt, patch1.1.txt, patch1.2.txt, schemavalidation.zip > > > When using SchemaUpdate, the DatabaseMetaData.getTableMetadata() looks for a table with the correct table name in any database schema and it take the first one it found. This behavior is uncorrect if I have a table existing in different schemas. > The correct behavior would be to first look in the schema with the login name and after in any schema. > user1.article > user2.article > I connected whith user2, DatabaseMetaData should first look for user2.article, then if not found to %.article. > Adrien -- 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

19 years, 1 month

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-1046) Make Criteria & DetachedCriteria cloneable

by Max Rydahl Andersen (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1046?page=c... ] Max Rydahl Andersen commented on HHH-1046: ------------------------------------------ patches are much better in ensuring progress.... > Make Criteria & DetachedCriteria cloneable > ------------------------------------------ > > Key: HHH-1046 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1046 > Project: Hibernate3 > Type: Improvement > Components: core > Versions: 3.0.5 > Environment: Hibernate 3.0.5, Database irrelevant > Reporter: Corey Puffalt > Priority: Minor > > > Criteria and in particular, DetachedCriteria would be substantially more useful if they were made cloneable either by implementing clone() or via some other method if Cloneable is abhorrent. > This has already come up a number of times on the forums where people want to do things like write general methods that can take a Criteria and perform a count on it. However, doing so has sideaffects (you've changed the Projection on the Criteria.) Some of these sideaffects are reversable but requires extra care and attention. Furthermore, not all operations are reversable. For instance, addOrder() etc. > In my opinion, it would greatly enhance the utility of these classes by providing this feature. -- 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

19 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues November 2006