[Hibernate-JIRA] Commented: (HHH-1293) java.lang.NoSuchMethodError: <persistent class>.getHibernateLazyInitializer()
by Thomas Dickey (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1293?page=c... ]
Thomas Dickey commented on HHH-1293:
------------------------------------
Prob a stupid question... but I get an error when I try to use the command svn diff -r9210:10126 CGLIBLazyInitializer.java > patch.CGLIBLazyInitializer.java
svn: '.' is not a working copy
svn: Can't open file '.svn/entries': No such file or directory
I am not very familer with svn but I think I need to download a working copy of the code first... ???
Can someone please post noob install steps for this fix. It's very frustrating....
Thanks!!
> java.lang.NoSuchMethodError: <persistent class>.getHibernateLazyInitializer()
> -----------------------------------------------------------------------------
>
> Key: HHH-1293
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1293
> Project: Hibernate3
> Type: Bug
> Versions: 3.1.1
> Reporter: Andreas Schildbach
> Assignee: Scott Marlow
> Priority: Blocker
> Fix For: 3.2.0.cr4
> Attachments: CGLIBLazyInitializer.patch, CGLIBLazyInitializer.patch, CGLIBLazyInitializer.patch3, CGLIBLazyInitializer.patch4, CGLIBProxyFactory.patch3, HibernateLazyInitializerTest.java, TestProcess.xml, hibernate.properties, hibernate3.jar, manysessions.tgz, patch.CGLIBLazyInitializer.java
>
>
> As documented in
> http://forum.hibernate.org/viewtopic.php?t=940119
> some people (including me) are getting this exception with the final release of Hibernate 3.1:
> java.lang.NoSuchMethodError: de.schildbach.game.integration.HibernateGamePlayer.getHibernateLazyInitializer()Lorg/hibernate/proxy/LazyInitializer;
> at de.schildbach.game.integration.HibernateGamePlayer$$EnhancerByCGLIB$$afecb986.getHibernateLazyInitializer(<generated>)
> at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:274)
> at org.hibernate.type.ManyToOneType.assemble(ManyToOneType.java:177)
> at org.hibernate.type.TypeFactory.assemble(TypeFactory.java:398)
> at org.hibernate.cache.entry.CacheEntry.assemble(CacheEntry.java:96)
> at org.hibernate.cache.entry.CacheEntry.assemble(CacheEntry.java:82)
> at org.hibernate.event.def.DefaultLoadEventListener.assembleCacheEntry(DefaultLoadEventListener.java:520)
> at org.hibernate.event.def.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:474)
> at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:328)
> at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:123)
> at org.hibernate.event.def.DefaultLoadEventListener.returnNarrowedProxy(DefaultLoadEventListener.java:202)
> at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:169)
> at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:87)
> at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:869)
> at org.hibernate.impl.SessionImpl.internalLoad(SessionImpl.java:838)
> at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:266)
> at org.hibernate.type.ManyToOneType.assemble(ManyToOneType.java:177)
> at org.hibernate.collection.PersistentList.initializeFromCache(PersistentList.java:378)
> at org.hibernate.cache.entry.CollectionCacheEntry.assemble(CollectionCacheEntry.java:35)
> at org.hibernate.event.def.DefaultInitializeCollectionEventListener.initializeCollectionFromCache(DefaultInitializeCollectionEventListener.java:130)
> at org.hibernate.event.def.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeCollectionEventListener.java:48)
> at org.hibernate.impl.SessionImpl.initializeCollection(SessionImpl.java:1627)
> at org.hibernate.collection.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:344)
> at org.hibernate.collection.AbstractPersistentCollection.read(AbstractPersistentCollection.java:86)
> at org.hibernate.collection.AbstractPersistentCollection.readSize(AbstractPersistentCollection.java:109)
> at org.hibernate.collection.PersistentList.size(PersistentList.java:91)
> The exception varies with the actual persistent class in use. Most people seem to be using JDK 1.5 and Linux. Some reports say that the exception does not happen from the very start of the application, but it takes "several invocations"/"some time" until it appear, but then it appears very often.
--
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
[Hibernate-JIRA] Created: (HHH-2256) inner join created for not-null="false" many-to-one property
by Stephen M. Wick (JIRA)
inner join created for not-null="false" many-to-one property
------------------------------------------------------------
Key: HHH-2256
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2256
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.1.2
Environment: MS SQL Server Desktop Ed., Hibernate 3.1.2
Reporter: Stephen M. Wick
Hibernate generates an inner join when a nullable many-to-one property is specified in the ORDER BY clause of an HQL statement.
If the property specified in the ORDER BY statement is nullable, then Hibernate should generate an OUTER JOIN to allow nulls in the result set. Instead, for whatever reason, Hibernate put's the property's table in the FROM clause, and JOINS the records with the parent table using a WHERE condition, which is basically an INNER JOIN. By performing the join this way, records with null values in the property being sorted upon are excluded from the query result set when they shouldn't be.
I also tried adding hibernate-mapping/class/many-to-one/@outer-join="true", and Hibernate generated the same SQL (inner join).
Example HQL: from Staff order by state.name
state is a many-to-one not-null="false" property of Staff.
Here's the SQL I expected to be generated:
select
...
from
STAFF staff0_
left outer join STATE state1_ on staff0_.STATE_ID = state1_.STATE_ID
order by
state1_.STATE_NAME asc
Here's the SQL that Hibernate generated:
select
...
from
STAFF staff0_,
State state1_
where
staff0_.STATE_ID = state1_.STATE_ID
order by
state1_.STATE_NAME asc
--
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
[Hibernate-JIRA] Resolved: (HHH-1851) relax special handling of 'id' property
by Steve Ebersole (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1851?page=all ]
Steve Ebersole resolved HHH-1851:
---------------------------------
Resolution: Fixed
trunk / 3.2
> relax special handling of 'id' property
> ---------------------------------------
>
> Key: HHH-1851
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1851
> Project: Hibernate3
> Type: Improvement
> Components: query-hql
> Environment: independent, all versions all databases.
> Reporter: Gunther Schadow
> Assignee: Steve Ebersole
> Fix For: 3.2.2
>
>
> Hibernate has long treated 'id' in a special manner in HQL and Criteria queries. The drawback to this has always been that it effectively means users cannot define non-identifier properties named id and refer to those properties in HQL/Criteria queries.
> Thus, I will change this such that:
> (1) 'id' can still be used to refer to the identifier property, whatever the property's actual name, as long as the entity does not define a non-identitifer property named id.
> (2) if the entity defines a non-identifier property named 'id', using 'id' in HQL or Criteria queries will refer to this non-identifier property; users would need to refer to the identifier property by its actual name.
> FYI, the original reason for this feature was to support entity's which did not define an identifier property at all (users were responsible for managing the ids seperately. That feature was never really recommended and has been deprecated since early in the 3.x development.
--
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
[Hibernate-JIRA] Commented: (HHH-1329) SchemaValidator skips views on Oracle
by Jörg Heinicke (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1329?page=c... ]
Jörg Heinicke commented on HHH-1329:
------------------------------------
Just wondering why it takes one year to fix such a bug? Hibernate claims often enough that views are handled like tables (e.g. http://www.hibernate.org/116.html#A27), but that's just not true due to this bug. And it is a BUG, not only an improvement, even if it only occurs on schema validation.
Instead of
<class name="MyClass" table="MY_VIEW">
...
</class>
I have to write
<class name="MyClass" table="MY_VIEW">
<subselect>select * from MY_VIEW</subselect>
...
</class>
I'm using IBM DB 2 btw, so it's no Oracle specific problem.
Jörg
> SchemaValidator skips views on Oracle
> -------------------------------------
>
> Key: HHH-1329
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1329
> Project: Hibernate3
> Type: Improvement
> Components: metamodel
> Versions: 3.1
> Environment: database: oracle9i
> hibernate: 3.1
> jdbc driver: ojdbc14-10.2.0.1.0
> Reporter: Yariv Yaari
>
>
> All calls in org.hibernate.tool.hbm2ddl.DatabaseMetadata.getTableMetadata to java.sql.DatabaseMetaData.getTables set the fourth parameter (types) to {"TABLE"} (defined as a class-level constant).
> In the documentation of getTables it is not defined what are the meanings of the types passed as parameter, only that all the strings must be in java.sql.DatabaseMetaData.getTablesTypes return value. In oracle9i with ojdbc14-10.2.0.1.0.jar views are returned if types contains "VIEW" and not if its {"TABLE"}. It is a major problem only if hibernate.hbm2ddl.auto is set to validate, if it's set to update it will log some errors (since it can't create or alter the table, there is a view with this name) but it won't fail the deployment, and since in SQL views are treated as tables, there will be no more problems.
> It should be checked for more databases/jdbc drivers.
> It is not obvious what should be the solution.
> Pass {"TABLE","VIEW"} always? Pass them if they are in getTableTypes?
> Put it as part of the dialect, default to {"TABLE"} and change it in oreacle-dialects?
--
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
[Hibernate-JIRA] Updated: (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=all ]
Steve Finch updated HHH-1889:
-----------------------------
Attachment: SQLServerDialect.applyLocks.patch
I'm attaching a second patch that fixes the use of inline lock hints for HQL and Criteria queries. I thought it would be harder than it was, but I've tested it and it works as expected.
My methodology:
1) Locate all the places where ForUpdateFragment is appended to the existing SQL (QueryTranslatorImpl, QueryLoader, and CriteriaLoader);
2) Refactor the code to move this behavior to the Dialect class;
3) Override the new method in the SQLServerDialect class;
4) Create a new class InlineUpdateLockModification which replaces the aliases in the FROM clause with the appropriate update lock hint, if necessary.
I'm not exactly happy with the solution, as it causes the query to be reprocessed each time lock hints occur. However, it seemed a lesser risk than playing with the HQLQueryPlanKey class and adding some metadata about what locks would be needed. My fix could be sped up if there were bookmarks telling where each alias existed in the existing query; with that information a search would not be necessary and the resulting code would be safer.
> 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
> Attachments: AbstractEntityJoinWalker.java.patch, SQLServerDialect.applyLocks.patch
>
>
> 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
[Hibernate-JIRA] Updated: (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=all ]
Steve Finch updated HHH-1889:
-----------------------------
Attachment: AbstractEntityJoinWalker.java.patch
I've attached a patch file for AbstractEntityJoinWalker.java, which should suffice in finishing of the Session portion of this problem.
> 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
> Attachments: AbstractEntityJoinWalker.java.patch
>
>
> 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
[Hibernate-JIRA] Created: (HHH-2255) Provide way around DB limitation for large "where x in (...)"
by Gerald Glocker (JIRA)
Provide way around DB limitation for large "where x in (...)"
-------------------------------------------------------------
Key: HHH-2255
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2255
Project: Hibernate3
Type: Improvement
Components: query-hql, query-criteria, core
Versions: 3.2.1
Reporter: Gerald Glocker
In-Restrictions with a large number of elements lead to database sql errors (e.g. ORA-01795 in Oracle).
This issue came up on Hbernate 2 earlier (HB-655) but wasn't fixed for unknwon reasons.
The maximum IN list size in Oracle is 1000. Other DBs may also have similar limitations.
To work around these DB limits, large In-Restrictions in HQL/Criteria could be split into multiple In-Restrictions combined as disjunction:
x in (1,2,3,4...)
could be split into:
(x in (1,2,3,4,...)
or (x in (1001,1002,1003,....)
Shoul also be done for composite-values: "(x, y) in ((1,1), (1,2), (1,3), ...)"
--
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
[Hibernate-JIRA] Updated: (HHH-1851) relax special handling of 'id' property
by Steve Ebersole (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1851?page=all ]
Steve Ebersole updated HHH-1851:
--------------------------------
Version: (was: 3.0 alpha)
(was: 3.0 beta 1)
(was: 3.0 beta 2)
(was: 3.0 beta 3)
(was: 3.0 beta 4)
(was: 3.0 rc 1)
(was: 3.0 final)
(was: 3.0.1)
(was: 3.0.2)
(was: 3.0.3)
(was: 3.0.4)
(was: 3.0.5)
(was: 3.1 beta 1)
(was: 3.1 beta 2)
(was: 3.1 rc 1)
(was: 3.1 rc2)
(was: 3.1 rc3)
(was: 3.1)
(was: 3.1.1)
(was: 3.1.2)
(was: 3.1.3)
Original Estimate: (was: 1 hour)
Remaining Estimate: (was: 1 hour)
> relax special handling of 'id' property
> ---------------------------------------
>
> Key: HHH-1851
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1851
> Project: Hibernate3
> Type: Improvement
> Components: query-hql
> Environment: independent, all versions all databases.
> Reporter: Gunther Schadow
> Assignee: Steve Ebersole
> Fix For: 3.2.2
>
>
> Hibernate has long treated 'id' in a special manner in HQL and Criteria queries. The drawback to this has always been that it effectively means users cannot define non-identifier properties named id and refer to those properties in HQL/Criteria queries.
> Thus, I will change this such that:
> (1) 'id' can still be used to refer to the identifier property, whatever the property's actual name, as long as the entity does not define a non-identitifer property named id.
> (2) if the entity defines a non-identifier property named 'id', using 'id' in HQL or Criteria queries will refer to this non-identifier property; users would need to refer to the identifier property by its actual name.
> FYI, the original reason for this feature was to support entity's which did not define an identifier property at all (users were responsible for managing the ids seperately. That feature was never really recommended and has been deprecated since early in the 3.x development.
--
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
[Hibernate-JIRA] Updated: (HHH-1851) relax special handling of 'id' property
by Steve Ebersole (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1851?page=all ]
Steve Ebersole updated HHH-1851:
--------------------------------
Summary: relax special handling of 'id' property (was: "special" identifier property in HQL unnecessaryily causing problems)
Description:
Hibernate has long treated 'id' in a special manner in HQL and Criteria queries. The drawback to this has always been that it effectively means users cannot define non-identifier properties named id and refer to those properties in HQL/Criteria queries.
Thus, I will change this such that:
(1) 'id' can still be used to refer to the identifier property, whatever the property's actual name, as long as the entity does not define a non-identitifer property named id.
(2) if the entity defines a non-identifier property named 'id', using 'id' in HQL or Criteria queries will refer to this non-identifier property; users would need to refer to the identifier property by its actual name.
FYI, the original reason for this feature was to support entity's which did not define an identifier property at all (users were responsible for managing the ids seperately. That feature was never really recommended and has been deprecated since early in the 3.x development.
was:
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!
> relax special handling of 'id' property
> ---------------------------------------
>
> Key: HHH-1851
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1851
> Project: Hibernate3
> Type: Improvement
> Components: query-hql
> Environment: independent, all versions all databases.
> Reporter: Gunther Schadow
> Assignee: Steve Ebersole
> Fix For: 3.2.2
>
> Original Estimate: 1 hour
> Remaining: 1 hour
>
> Hibernate has long treated 'id' in a special manner in HQL and Criteria queries. The drawback to this has always been that it effectively means users cannot define non-identifier properties named id and refer to those properties in HQL/Criteria queries.
> Thus, I will change this such that:
> (1) 'id' can still be used to refer to the identifier property, whatever the property's actual name, as long as the entity does not define a non-identitifer property named id.
> (2) if the entity defines a non-identifier property named 'id', using 'id' in HQL or Criteria queries will refer to this non-identifier property; users would need to refer to the identifier property by its actual name.
> FYI, the original reason for this feature was to support entity's which did not define an identifier property at all (users were responsible for managing the ids seperately. That feature was never really recommended and has been deprecated since early in the 3.x development.
--
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