hibernate-issues — Hibernate JIRA Notifications

[Hibernate-issues] [Hibernate-JIRA] Closed: (HBX-701) reveng and hbm2java might not be treating not-null/types equally

[Max R. A. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HBX-701?page=all ]
     
Max Rydahl Andersen closed HBX-701:
-----------------------------------

    Resolution: Rejected

The case described is not true.

reveng generates "long" properties  for columns that is marked as NOT NULL at the db layer.

hbm2java will then generate a "long".

But if you write type="java.lang.Long" it will generate "java.lang.Long".

> reveng and hbm2java might not be treating not-null/types equally
> ----------------------------------------------------------------
>
>          Key: HBX-701
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-701
>      Project: Hibernate Tools
>         Type: Task

>   Components: hbm2java
>     Reporter: Max Rydahl Andersen
>      Fix For: 3.2beta6

>
>
> confirm or reject what http://chimogiratorio.blogspot.com/2006/05/tipos-wrapper-e-hibernate-tools.html is hinting.
> the blog says its a problem with codegen, but the fixes is in the reverse engineering part - can only then be true
> if he is generating directly from the reverse engineered result and then it looks weird if not-null="true" and type is java.lang.Long ...something is wrong here.

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Closed: (HBX-702) org.hibernate.eclipse.console only works on jdk 1.5

[Max R. A. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HBX-702?page=all ]
     
Max Rydahl Andersen closed HBX-702:
-----------------------------------

    Fix Version: 3.2beta7
     Resolution: Fixed

found a nonneeded plugin dependency  org.eclipse.jdt.apt.core.

fixed in svn

> org.hibernate.eclipse.console only works on jdk 1.5
> ---------------------------------------------------
>
>          Key: HBX-702
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-702
>      Project: Hibernate Tools
>         Type: Improvement

>     Versions: 3.2beta6
>     Reporter: Max Rydahl Andersen
>      Fix For: 3.2beta7

>
>
> plugins not available on jdk 1.4, only jdk 1.5

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HBX-702) org.hibernate.eclipse.console only works on jdk 1.5

[Max R. A. (JIRA) <no...@at...>]

org.hibernate.eclipse.console only works on jdk 1.5
---------------------------------------------------

         Key: HBX-702
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-702
     Project: Hibernate Tools
        Type: Improvement

    Versions: 3.2beta6    
    Reporter: Max Rydahl Andersen


plugins not available on jdk 1.4, only jdk 1.5

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-879) Enable joining the same association twice with Criteria

[Jos D. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-879?page=comments#action_23581 ] 

Jos Dirksen commented on HHH-879:
---------------------------------

This issue also causes problems for us and pretty much doesn't allow us to use the criteria API.  So a fix for this would be very much appreciated.

> Enable joining the same association twice with Criteria
> -------------------------------------------------------
>
>          Key: HHH-879
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-879
>      Project: Hibernate3
>         Type: Improvement

>   Components: core
>     Reporter: Vladimir Bayanov

>
>
> Make double joining the same association with Criteria.createCriteria possible. See: http://forum.hibernate.org/viewtopic.php?t=931249

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HHH-1891) Since rc3 deprecation Warning: The syntax 'TYPE=storage_engine' is deprecated and will be removed in MySQL 5.2.

[<no...@at...>]

Since rc3 deprecation Warning: The syntax 'TYPE=3Dstorage_engine' is deprec=
ated and will be removed in MySQL 5.2.
---------------------------------------------------------------------------=
------------------------------------

         Key: HHH-1891
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH=
-1891
     Project: Hibernate3
        Type: Bug

    Versions: 3.2.0.cr3   =20
 Environment: I use MySQL 5.1.11-bata on Windows XP.
mysql-connector-java-3.1.13-bin.jar
My settings:
hibernate.dialect org.hibernate.dialect.MySQLInnoDBDialect
hibernate.connection.driver_class com.mysql.jdbc.Driver

    Reporter: Stefan B=C3=BChlmann
    Priority: Minor


Since cr3 I get the following warning (cr2 goes without it):

09.07.2006 11:10:11 org.hibernate.tool.hbm2ddl.SchemaExport execute
INFO: exporting generated schema to database
09.07.2006 11:10:14 org.hibernate.util.JDBCExceptionReporter logWarnings
WARNUNG: SQL Warning: 1541, SQLState: HY000
09.07.2006 11:10:14 org.hibernate.util.JDBCExceptionReporter logWarnings
WARNUNG: The syntax 'TYPE=3Dstorage_engine' is deprecated and will be remov=
ed in MySQL 5.2. Please use 'ENGINE=3Dstorage_engine' instead.
09.07.2006 11:10:14 org.hibernate.util.JDBCExceptionReporter logWarnings
WARNUNG: SQL Warning: 1541, SQLState: HY000


--=20
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1887) SortedSet broken in 3.2.0.cr3

[<no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1887?pa=
ge=3Dcomments#action_23580 ]=20

Stefan B=C3=BChlmann commented on HHH-1887:
--------------------------------------

This seems to be the same as my problem. Here my description:
Since cr3 java.lang.ClassCastException: java.util.HashSet cannot be cast to=
 java.util.SortedSet in PersistentSortedSet.tailSet

I've got a sorted to-many mapping, wich causes the above ClassCastException=
 since cr3 (it works fine in cr2).
The mapping is:

<set name=3D"Elements" inverse=3D"true" sort=3D"x2.elements.baseImpl.Elemen=
t$ComparatorByElemNo" >
       =09<key column=3D"INSTALLATION"/>
        <one-to-many class=3D"x2.elements.baseImpl.Element"/>
</set>

Here the instance variable:
private SortedSet<Element> elements =3D new TreeSet<Element>(Element.getCom=
paratorByElemNo());

I execute the following line of code:

SortedSet<Element> tailSet =3D elements.tailSet(tmp); // Here I get the Cla=
ssCastException

Immediately before the call to tailSet I have the following in the debugger=
:
this=09Installation  (id=3D32)=09
=09elements=09PersistentSortedSet  (id=3D90)=09// the object on which I cal=
l tailSet
=09=09cachedSize=09-1=09
=09=09comparator=09Element$ComparatorByElemNo  (id=3D94)=09
=09=09directlyAccessible=09false=09
=09=09dirty=09false=09
=09=09initialized=09false=09
=09=09initializing=09false=09
=09=09key=09Long  (id=3D97)=09
=09=09operationQueue=09null=09
=09=09owner=09Installation  (id=3D32)=09
=09=09role=09"x2.elements.baseImpl.Installation.Elements"=09
=09=09session=09SessionImpl  (id=3D101)=09
=09=09set=09null=09=09=09// obviously not fetched yet
=09=09storedSnapshot=09null=09
=09=09tempList=09null=09
=09id=091=09
=09name=09"in1"=09
=09nextElemNo=095=09
=09nextTrxNo=092=09

now executing the line:
        SortedSet<Element> tailSet =3D elements.tailSet(tmp);

Immediately after the call (when the exception is raised):
in1=09Installation  (id=3D32)=09
=09elements=09PersistentSortedSet  (id=3D90)=09
=09=09cachedSize=09-1=09
=09=09comparator=09Element$ComparatorByElemNo  (id=3D94)=09
=09=09directlyAccessible=09false=09
=09=09dirty=09false=09
=09=09initialized=09true=09
=09=09initializing=09false=09
=09=09key=09Long  (id=3D97)=09
=09=09operationQueue=09null=09
=09=09owner=09Installation  (id=3D32)=09
=09=09role=09"x2.elements.baseImpl.Installation.Elements"=09
=09=09session=09SessionImpl  (id=3D101)=09
=09=09set=09HashSet<E>  (id=3D138)=09=09=09// could this be the problem?
=09=09storedSnapshot=09HashMap<K,V>  (id=3D140)=09
=09=09tempList=09null=09
=09id=091=09
=09name=09"in1"=09
=09nextElemNo=095=09
=09nextTrxNo=092=09

Here the full stack trace:
java.lang.ClassCastException: java.util.HashSet cannot be cast to java.util=
.SortedSet
=09at org.hibernate.collection.PersistentSortedSet.tailSet(PersistentSorted=
Set.java:85)
=09at x2.elements.baseImpl.Installation.findElement(Installation.java:130) =
// the line of the above call
=09at x2.elements.baseImpl.ElementFactory.findElement(ElementFactory.java:2=
63)
=09at x2.elements.baseImpl.ElementFactory.findElement(ElementFactory.java:1=
)
=09at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
=09at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.=
java:39)
=09at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces=
sorImpl.java:25)
=09at java.lang.reflect.Method.invoke(Method.java:589)
=09at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflecti=
on(AopUtils.java:266)
=09at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJo=
inpoint(ReflectiveMethodInvocation.java:181)
=09at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(=
ReflectiveMethodInvocation.java:148)
=09at org.springframework.transaction.interceptor.TransactionInterceptor.in=
voke(TransactionInterceptor.java:100)
=09at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(=
ReflectiveMethodInvocation.java:170)
=09at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynami=
cAopProxy.java:176)
=09at $Proxy1.findElement(Unknown Source)
=09at brasil.tests.elements.ElementFactoryTC.testElementFactory(ElementFact=
oryTC.java:307)
=09at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
=09at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.=
java:39)
=09at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces=
sorImpl.java:25)
=09at java.lang.reflect.Method.invoke(Method.java:589)
=09at junit.framework.TestCase.runTest(TestCase.java:154)
=09at junit.framework.TestCase.runBare(TestCase.java:127)
=09at junit.framework.TestResult$1.protect(TestResult.java:106)
=09at junit.framework.TestResult.runProtected(TestResult.java:124)
=09at junit.framework.TestResult.run(TestResult.java:109)
=09at junit.framework.TestCase.run(TestCase.java:118)
=09at junit.framework.TestSuite.runTest(TestSuite.java:208)
=09at junit.framework.TestSuite.run(TestSuite.java:203)
=09at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(=
JUnit3TestReference.java:128)
=09at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution=
.java:38)
=09at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(Remot=
eTestRunner.java:460)
=09at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(Remot=
eTestRunner.java:673)
=09at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTest=
Runner.java:386)
=09at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTes=
tRunner.java:196)


> SortedSet broken in 3.2.0.cr3
> -----------------------------
>
>          Key: HHH-1887
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/H=
HH-1887
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.2.0.cr3
>  Environment: Hibernate 3.2.0.cr3, any database
>     Reporter: Daan Van Heghe

>
>
> the comparator for a SortedSet is no longer called in 3.2.0.cr3, works fi=
ne in 3.2.0.cr2.

--=20
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Updated: (HHH-1890) setMaxResult, distinct, joined collections optimization

[Emmanuel B. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1890?page=all ]

Emmanuel Bernard updated HHH-1890:
----------------------------------

      Component: core
        Summary: setMaxResult, distinct, joined collections optimization  (was: setMaxResult, distinct, )
    Description: 
As discussed months ago.
Instead of the current behavior, we can apply the first/max operations on the distinct ids and retrieve the fully loaded object graph from it, either:
 - creating a temp table, populating this temp table with insert ... select id from (my original
query), retrieving elements select from [my join path} where root.id in (select
temp table with first / max restriction)
 - or using a subselect (not sure it works for every cases
        Version: 3.2.0.cr3

> setMaxResult, distinct, joined collections optimization
> -------------------------------------------------------
>
>          Key: HHH-1890
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1890
>      Project: Hibernate3
>         Type: Improvement

>   Components: core
>     Versions: 3.2.0.cr3
>     Reporter: Emmanuel Bernard

>
>
> As discussed months ago.
> Instead of the current behavior, we can apply the first/max operations on the distinct ids and retrieve the fully loaded object graph from it, either:
>  - creating a temp table, populating this temp table with insert ... select id from (my original
> query), retrieving elements select from [my join path} where root.id in (select
> temp table with first / max restriction)
>  - or using a subselect (not sure it works for every cases

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HHH-1890) setMaxResult, distinct,

[Emmanuel B. (JIRA) <no...@at...>]

setMaxResult, distinct, 
------------------------

         Key: HHH-1890
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1890
     Project: Hibernate3
        Type: Improvement

    Reporter: Emmanuel Bernard




-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HBX-701) reveng and hbm2java might not be treating not-null/types equally

[Max R. A. (JIRA) <no...@at...>]

reveng and hbm2java might not be treating not-null/types equally
----------------------------------------------------------------

         Key: HBX-701
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-701
     Project: Hibernate Tools
        Type: Task

  Components: hbm2java  
    Reporter: Max Rydahl Andersen
     Fix For: 3.2beta6


confirm or reject what http://chimogiratorio.blogspot.com/2006/05/tipos-wrapper-e-hibernate-tools.html is hinting.

the blog says its a problem with codegen, but the fixes is in the reverse engineering part - can only then be true
if he is generating directly from the reverse engineered result and then it looks weird if not-null="true" and type is java.lang.Long ...something is wrong here.

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

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

[Matthias G. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1889?page=comments#action_23579 ] 

Matthias Germann commented on HHH-1889:
---------------------------------------

Setting the from clause by calling the dialect's appendLockHint() method in AbstractEntityJoinWalker.initStatementString() seams to solve the problem with the Session class but not with the QBC API:

.setFromClause(
  /*persister.fromTableFragment(alias) +*/
  getDialect().appendLockHint(lockMode, persister.fromTableFragment(alias)) +
  persister.fromJoinFragment(alias, true, true)
)


> 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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

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

[Matthias G. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1889?page=comments#action_23578 ] 

Matthias Germann commented on HHH-1889:
---------------------------------------

The LockMode.UPGRADE does also not work for SQL Server with the Query by Criteria API:

session.createCriteria(ProcessInstance.class)
    .add(Restrictions.idEq(33l))
    .setFetchMode("rootToken", FetchMode.JOIN)
    .createAlias("rootToken", "rootToken")
    .setLockMode("rootToken", LockMode.UPGRADE)
    .list();

proces the following SQL Statement with the SQLServer dialect:

    select
        this_.ID_ as ID1_20_1_,
        this_.VERSION_ as VERSION2_20_1_,
        this_.START_ as START3_20_1_,
        this_.END_ as END4_20_1_,
        this_.ISSUSPENDED_ as ISSUSPEN5_20_1_,
        this_.PROCESSDEFINITION_ as PROCESSD6_20_1_,
        this_.ROOTTOKEN_ as ROOTTOKEN7_20_1_,
        this_.SUPERPROCESSTOKEN_ as SUPERPRO8_20_1_,
        roottoken1_.ID_ as ID1_21_0_,
        roottoken1_.VERSION_ as VERSION2_21_0_,
        roottoken1_.NAME_ as NAME3_21_0_,
        roottoken1_.START_ as START4_21_0_,
        roottoken1_.END_ as END5_21_0_,
        roottoken1_.NODEENTER_ as NODEENTER6_21_0_,
        roottoken1_.NEXTLOGINDEX_ as NEXTLOGI7_21_0_,
        roottoken1_.ISABLETOREACTIVATEPARENT_ as ISABLETO8_21_0_,
        roottoken1_.ISTERMINATIONIMPLICIT_ as ISTERMIN9_21_0_,
        roottoken1_.ISSUSPENDED_ as ISSUSPE10_21_0_,
        roottoken1_.NODE_ as NODE11_21_0_,
        roottoken1_.PROCESSINSTANCE_ as PROCESS12_21_0_,
        roottoken1_.PARENT_ as PARENT13_21_0_,
        roottoken1_.SUBPROCESSINSTANCE_ as SUBPROC14_21_0_ 
    from
        JBPM_PROCESSINSTANCE this_ 
    inner join
        JBPM_TOKEN roottoken1_ 
            on this_.ROOTTOKEN_=roottoken1_.ID_ 
    where
        this_.ID_ = ?

Again, the lock hint is missing.

The OracleDialect produces a correct Statement with the lock clause:
    select
        this_.ID_ as ID1_20_1_,
        this_.VERSION_ as VERSION2_20_1_,
        this_.START_ as START3_20_1_,
        this_.END_ as END4_20_1_,
        this_.ISSUSPENDED_ as ISSUSPEN5_20_1_,
        this_.PROCESSDEFINITION_ as PROCESSD6_20_1_,
        this_.ROOTTOKEN_ as ROOTTOKEN7_20_1_,
        this_.SUPERPROCESSTOKEN_ as SUPERPRO8_20_1_,
        roottoken1_.ID_ as ID1_21_0_,
        roottoken1_.VERSION_ as VERSION2_21_0_,
        roottoken1_.NAME_ as NAME3_21_0_,
        roottoken1_.START_ as START4_21_0_,
        roottoken1_.END_ as END5_21_0_,
        roottoken1_.NODEENTER_ as NODEENTER6_21_0_,
        roottoken1_.NEXTLOGINDEX_ as NEXTLOGI7_21_0_,
        roottoken1_.ISABLETOREACTIVATEPARENT_ as ISABLETO8_21_0_,
        roottoken1_.ISTERMINATIONIMPLICIT_ as ISTERMIN9_21_0_,
        roottoken1_.ISSUSPENDED_ as ISSUSPE10_21_0_,
        roottoken1_.NODE_ as NODE11_21_0_,
        roottoken1_.PROCESSINSTANCE_ as PROCESS12_21_0_,
        roottoken1_.PARENT_ as PARENT13_21_0_,
        roottoken1_.SUBPROCESSINSTANCE_ as SUBPROC14_21_0_ 
    from
        JBPM_PROCESSINSTANCE this_,
        JBPM_TOKEN roottoken1_ 
    where
        this_.ROOTTOKEN_=roottoken1_.ID_ 
        and this_.ID_ = ? for update
            of roottoken1_.ID_




> 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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

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

[Matthias G. (JIRA) <no...@at...>]

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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HHH-1888) Logging uses getClass() rather than hard coded class

[Bryan Y. (JIRA) <no...@at...>]

Logging uses getClass() rather than hard coded class
----------------------------------------------------

         Key: HHH-1888
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1888
     Project: Hibernate3
        Type: Bug

    Versions: 3.0.1    
    Reporter: Bryan Young


NullableType logs against getClass() rather than NullableType.class.  This is undoubtably a miss-guided effort to stop copy/paste errors, but it means that NullableType logging will be turned on or off based on the subclasses package rather than the Hibernate package.

In our case, we subclassed StringType to change how char values are loaded from our database.  Turning on logging for our application also enables a lot of unwanted logging from within Hibernate.  Our subclass might be in the package com.mycompany.hibernate.extentions.  Turning debug logging on for only our code (com.mycompany) will also log debug information within NullableType.

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Closed: (HBX-573) last hibernate-tools don't make foreign key in Derby

[Max R. A. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HBX-573?page=all ]
     
Max Rydahl Andersen closed HBX-573:
-----------------------------------

    Resolution: Cannot Reproduce

i tried with latest derby (10.1.3.1) and i don't see this. they return "" but also respond to "" accordingly.

> last hibernate-tools don't make foreign key in Derby
> ----------------------------------------------------
>
>          Key: HBX-573
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-573
>      Project: Hibernate Tools
>         Type: Bug

>     Reporter: Haris Peco

>
>
> hibernate-tools beta4 +, derby
> Hi,
> bug is in
> JDBCReader.java line 463
> Table table = dbs.addTable(quote(getSchemaForModel(schemaName)),
> getCatalogForModel(catalogName), quote(tableName));
> when schema = default_schema then getSchemaForModel(schemaName)) return null
> i try remove default_schema and then tools don't nullify catalog ="" (derby driver return
> catalog="" in getExportedKeys)

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1887) SortedSet broken in 3.2.0.cr3

[Daan V. H. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1887?page=comments#action_23576 ] 

Daan Van Heghe commented on HHH-1887:
-------------------------------------

Error occurs when the set is loaded in a new session, but not when the set is being populated.

> SortedSet broken in 3.2.0.cr3
> -----------------------------
>
>          Key: HHH-1887
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1887
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.2.0.cr3
>  Environment: Hibernate 3.2.0.cr3, any database
>     Reporter: Daan Van Heghe

>
>
> the comparator for a SortedSet is no longer called in 3.2.0.cr3, works fine in 3.2.0.cr2.

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HHH-1887) SortedSet broken in 3.2.0.cr3

[Daan V. H. (JIRA) <no...@at...>]

SortedSet broken in 3.2.0.cr3
-----------------------------

         Key: HHH-1887
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1887
     Project: Hibernate3
        Type: Bug

  Components: core  
    Versions: 3.2.0.cr3    
 Environment: Hibernate 3.2.0.cr3, any database
    Reporter: Daan Van Heghe


the comparator for a SortedSet is no longer called in 3.2.0.cr3, works fine in 3.2.0.cr2.

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HHH-1886) unexpected AST node from where (id1, id2) in ((1, 2), (3, 4))

[Brian C. (JIRA) <no...@at...>]

unexpected AST node from where (id1,id2) in ((1,2), (3,4))
----------------------------------------------------------

         Key: HHH-1886
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1886
     Project: Hibernate3
        Type: Bug

  Components: query-hql  
    Versions: 3.1.2    
 Environment: Hibernate 3.1.2  Postgres 8.1.2
    Reporter: Brian Cox
 Attachments: hql.zip

ANSI SQL allows: WHERE ((id1, id2)) IN ((1,2), (3,4)); but the HQL parser throws org.hibernate.hql.ast.QuerySyntaxException (see stack trace below).   I've fixed this by modifying hql.g and sql-gen.g (attached below).  Note that these mods caused a NullPointerException due to use of LA(0) in weakKeywords() (see HHH-1885) that I worked around by adding LT(0) != null
before the LA(0) call; however, this does NOT fix the underlying problem [the use of LA(0)]

org.hibernate.hql.ast.QuerySyntaxException: unexpected AST node: {vector} [select new com.timestock.tess.data.objects.StatsAggregationData(b.id,b.user,b.transet,b.tranunit,b.userGroup,b.transetGroup,...) from com.timestock.tess.data.objects.StatsTranSetUserGroupInterval b where b.intervalStartTime >= :startTime and b.intervalStartTime < :endTime and (b.transet,b.userGroup) in ((0,0),(600000000000000030,600000000000000137))
at org.hibernate.hql.ast.ErrorCounter.throwQueryException(ErrorCounter.java:59)
at org.hibernate.hql.ast.QueryTranslatorImpl.generate(QueryTranslatorImpl.java:209)
at org.hibernate.hql.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:178)
at org.hibernate.hql.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:109)
at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:75)
at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:54)
at org.hibernate.engine.query.QueryPlanCache.getHQLQueryPlan(QueryPlanCache.java:71)
at org.hibernate.impl.AbstractSessionImpl.getHQLQueryPlan(AbstractSessionImpl.java:134)
at org.hibernate.impl.AbstractSessionImpl.createQuery(AbstractSessionImpl.java:113)
at org.hibernate.impl.SessionImpl.createQuery(SessionImpl.java:1602)
at com.timestock.tess.util.StatisticsAggregation.getDatabaseRows(StatisticsAggregation.java:410)
at com.timestock.tess.util.StatisticsAggregation.getDatabaseRows(StatisticsAggregation.java:334)
at com.timestock.tess.util.StatisticsAggregation.getAggregatedRows(StatisticsAggregation.java:222)
at com.timestock.tess.util.TranSetAggregation.AggregateGroup(TranSetAggregation.java:259)
at com.timestock.tess.util.TranSetAggregation.AggregateGroupHourly(TranSetAggregation.java:69)
at com.timestock.tess.services.processors.StatsProcessor.doIntervalAggregation(StatsProcessor.java:732)
at com.timestock.tess.services.processors.StatsProcessor.doIntervalAggregations(StatsProcessor.java:705)
at com.timestock.tess.services.processors.StatsProcessor.processStats(StatsProcessor.java:418)
at com.timestock.tess.services.collectors.StatsCollector$StatisticsCollector.run(StatsCollector.java:559)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
Caused by: <AST>:0:0: unexpected AST node: {vector}
at org.hibernate.hql.antlr.SqlGeneratorBase.inList(SqlGeneratorBase.java:3016)
at org.hibernate.hql.antlr.SqlGeneratorBase.exoticComparisonExpression(SqlGeneratorBase.java:2831)
at org.hibernate.hql.antlr.SqlGeneratorBase.comparisonExpr(SqlGeneratorBase.java:1203)
at org.hibernate.hql.antlr.SqlGeneratorBase.booleanExpr(SqlGeneratorBase.java:851)
at org.hibernate.hql.antlr.SqlGeneratorBase.booleanOp(SqlGeneratorBase.java:2541)
at org.hibernate.hql.antlr.SqlGeneratorBase.booleanExpr(SqlGeneratorBase.java:831)
at org.hibernate.hql.antlr.SqlGeneratorBase.whereExpr(SqlGeneratorBase.java:724)
at org.hibernate.hql.antlr.SqlGeneratorBase.selectStatement(SqlGeneratorBase.java:184)
at org.hibernate.hql.antlr.SqlGeneratorBase.statement(SqlGeneratorBase.java:117)
at org.hibernate.hql.ast.QueryTranslatorImpl.generate(QueryTranslatorImpl.java:203)
... 19 more 

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HHH-1885) LA(0) is undefined

[Brian C. (JIRA) <no...@at...>]

LA(0) is undefined
------------------

         Key: HHH-1885
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1885
     Project: Hibernate3
        Type: Bug

  Components: query-hql  
    Versions: 3.1.2    
 Environment: Hibernate 3.1.2  Postgres 8.1.2
    Reporter: Brian Cox


method weakKeywords() in org.hibernate.hql.ast.HqlParser.java has:

if (LA(0) == FROM && t != IDENT && LA(2) == DOT) {
...
}

According to a posting on the antlr mailing list [see "LT(0) Specification" posted 1 July 2006],
LA(i) and LT(i) are defined only for i > 0. Examining the code supports this assertion.  Also these
methods are documented as "lookahead" not "lookbehind".  LT(0) can return NULL and then LA(0)
will throw a NullPointerException as shown:

java.lang.NullPointerException
	at antlr.TokenBuffer.LA(TokenBuffer.java:81)
	at antlr.LLkParser.LA(LLkParser.java:52)
	at org.hibernate.hql.ast.HqlParser.weakKeywords(HqlParser.java:296)
	at org.hibernate.hql.antlr.HqlBaseParser.negatedExpression(HqlBaseParser.java:2366)
	at org.hibernate.hql.antlr.HqlBaseParser.logicalAndExpression(HqlBaseParser.java:2331)
	at org.hibernate.hql.antlr.HqlBaseParser.logicalOrExpression(HqlBaseParser.java:2296)
	at org.hibernate.hql.antlr.HqlBaseParser.expression(HqlBaseParser.java:2082)
	at org.hibernate.hql.antlr.HqlBaseParser.compoundExpr(HqlBaseParser.java:2991)
	at org.hibernate.hql.antlr.HqlBaseParser.inList(HqlBaseParser.java:2858)
	at org.hibernate.hql.antlr.HqlBaseParser.relationalExpression(HqlBaseParser.java:2720)
	at org.hibernate.hql.antlr.HqlBaseParser.equalityExpression(HqlBaseParser.java:2449)
	at org.hibernate.hql.antlr.HqlBaseParser.negatedExpression(HqlBaseParser.java:2413)
	at org.hibernate.hql.antlr.HqlBaseParser.logicalAndExpression(HqlBaseParser.java:2331)
	at org.hibernate.hql.antlr.HqlBaseParser.logicalOrExpression(HqlBaseParser.java:2296)
	at org.hibernate.hql.antlr.HqlBaseParser.expression(HqlBaseParser.java:2082)
	at org.hibernate.hql.antlr.HqlBaseParser.logicalExpression(HqlBaseParser.java:1858)
	at org.hibernate.hql.antlr.HqlBaseParser.whereClause(HqlBaseParser.java:454)
	at org.hibernate.hql.antlr.HqlBaseParser.updateStatement(HqlBaseParser.java:224)
	at org.hibernate.hql.antlr.HqlBaseParser.statement(HqlBaseParser.java:142)
	at org.hibernate.hql.ast.QueryTranslatorImpl.parse(QueryTranslatorImpl.java:238)
	at org.hibernate.hql.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:155)
	at org.hibernate.hql.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:109)
	at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:75)
	at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:54)
	at org.hibernate.engine.query.QueryPlanCache.getHQLQueryPlan(QueryPlanCache.java:71)
	at org.hibernate.impl.AbstractSessionImpl.getHQLQueryPlan(AbstractSessionImpl.java:134)
	at org.hibernate.impl.AbstractSessionImpl.createQuery(AbstractSessionImpl.java:113)
	at org.hibernate.impl.SessionImpl.createQuery(SessionImpl.java:1602)
	at com.timestock.tess.util.DbUtils.saveUpdatedUsers(DbUtils.java:38)
	at com.timestock.tess.services.collectors.StatsCollector$StatisticsCollector.run(StatsCollector.java:602)
	at java.util.TimerThread.mainLoop(Timer.java:512)
	at java.util.TimerThread.run(Timer.java:462)



-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (ANN-389) @ManyToMany without mappedBy should be recognized as an error

[Christopher G. S. II (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/ANN-389?page=comments#action_23575 ] 

Christopher G. Stach II commented on ANN-389:
---------------------------------------------

Okay, that makes complete sense.  So, basically, Hibernate is assuming that it has two unidirectional relationships instead of one bidirectional.  Thanks.

> @ManyToMany without mappedBy should be recognized as an error
> -------------------------------------------------------------
>
>          Key: ANN-389
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-389
>      Project: Hibernate Annotations
>         Type: Bug

>   Components: binder
>     Versions: 3.2.0.cr1
>     Reporter: Christopher G. Stach II

>
>
> Instead of letting the user know that something might get hosed, it creates two join tables, one for each direction.  I don't know when this would be the preferred behavior.

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (ANN-389) @ManyToMany without mappedBy should be recognized as an error

[Emmanuel B. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/ANN-389?page=comments#action_23574 ] 

Emmanuel Bernard commented on ANN-389:
--------------------------------------

No, I mean that you can have 2 different associations one from A to B and one from B to A where the semantic of the association are completly different

let's say

User --owner--> Car
Car --hasBeenDrivenBy'--> User

So in this case I do have 2 different associations with a completly different semantic, none of them are bidirectional (but they could).

Sorry, my previous comment wasn't really clear

> @ManyToMany without mappedBy should be recognized as an error
> -------------------------------------------------------------
>
>          Key: ANN-389
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-389
>      Project: Hibernate Annotations
>         Type: Bug

>   Components: binder
>     Versions: 3.2.0.cr1
>     Reporter: Christopher G. Stach II

>
>
> Instead of letting the user know that something might get hosed, it creates two join tables, one for each direction.  I don't know when this would be the preferred behavior.

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-355) Identifier is too long

[Andrea A. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-355?page=comments#action_23573 ] 

Andrea Aime commented on HHH-355:
---------------------------------

While I don't have a simple example, I can tell you how this long names are created. I do have a hierarchy mapped with the table per class approach, with intermediate abstract classes.

Leaf classes of this hierarchy are apparently managed in hibernate usign the DenormalizedTable class. The code that generates the foreign keys for this class is:

public void createForeignKeys() {
		includedTable.createForeignKeys();
		Iterator iter = includedTable.getForeignKeyIterator();
		while ( iter.hasNext() ) {
			ForeignKey fk = (ForeignKey) iter.next();
			createForeignKey( 
					fk.getName() + Integer.toHexString( getName().hashCode() ), 
					fk.getColumns(), 
					fk.getReferencedEntityName() 
				);
		}
	}

As you can see, it gets the foreign key name of the contained class, and appends another hexstring. This name can become really long if the 
hierarchy has many levels. In my case I get names as long as: FK14F780C41886F83e63ff56e238e868d73630607

> Identifier is too long
> ----------------------
>
>          Key: HHH-355
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-355
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.0 final
>  Environment: Oracle 9, JDK 1.5
>     Reporter: Tim McCune

>
>
> SchemaUpdate is trying to create a foreign key constraint whose name is too long for Oracle:
> 2005-04-15 12:25:26,444 ERROR [org.hibernate.tool.hbm2ddl.SchemaUpdate] Unsuccessful: alter table LoadDescriptor add constraint FK18D5ABAD371DC5BAba9c69f2d683d915 foreign key (parent) references Workspace
> 2005-04-15 12:25:26,444 ERROR [org.hibernate.tool.hbm2ddl.SchemaUpdate] [Oracle] #60 ORA-00972: identifier is too long

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (ANN-389) @ManyToMany without mappedBy should be recognized as an error

[Christopher G. S. II (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/ANN-389?page=comments#action_23572 ] 

Christopher G. Stach II commented on ANN-389:
---------------------------------------------

EJB 3.0 Final:

2.1.7 Entity Relationships

The following rules apply to bidirectional relationships:

* The inverse side of a bidirectional relationship must refer to its owning side by use of the mappedBy element of the OneToOne, OneToMany, or ManyToMany annotation. The mappedBy element designates the property or field in the entity that is the owner of the relationship.

[...]

* For many-to-many bidirectional relationships either side may be the owning side.


I don't think that the second point allows for BOTH sides to be the owning side because that would clearly violate the first point.


9.1.26 ManyToMany Annotation

Every many-to-many association has two sides, the owning side and the non-owning, or inverse, side.


This does not say "only some many-to-many associations have two sides."

Besides the spec saying that it "must" have mappedBy on one of the sides, it's a retarded use case to have duplicate join tables for the same relation.  Who does that and why?


> @ManyToMany without mappedBy should be recognized as an error
> -------------------------------------------------------------
>
>          Key: ANN-389
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-389
>      Project: Hibernate Annotations
>         Type: Bug

>   Components: binder
>     Versions: 3.2.0.cr1
>     Reporter: Christopher G. Stach II

>
>
> Instead of letting the user know that something might get hosed, it creates two join tables, one for each direction.  I don't know when this would be the preferred behavior.

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HHH-1884) Component doesnt support field access for parent

[Nick M. (JIRA) <no...@at...>]

Component doesnt support field access for parent
------------------------------------------------

         Key: HHH-1884
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1884
     Project: Hibernate3
        Type: Bug

  Components: core  
    Versions: 3.1.3    
    Reporter: Nick Minutello


Seems to support field access for everything else....

A number of ppl have run into this - see here:
http://forum.hibernate.org/viewtopic.php?p=2313355#2313355

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Closed: (HBX-699) Incorrect code generation for query-param elements

[Max R. A. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HBX-699?page=all ]
     
Max Rydahl Andersen closed HBX-699:
-----------------------------------

    Fix Version: 3.2beta6
     Resolution: Cannot Reproduce

please test against latest Hibernate being bundled with the tools ...and if it still existi please open a case with a simple mapping example that fails.

> Incorrect code generation for query-param elements
> --------------------------------------------------
>
>          Key: HBX-699
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-699
>      Project: Hibernate Tools
>         Type: Bug

>   Components: hbm2java
>     Versions: 3.2beta6
>  Environment: Hibernate 3/MySql 5.X
>     Reporter: Jak Mang
>      Fix For: 3.2beta6

>
>
> Query params in xml mapping files generate incorrect code for integers and possibly other scalers. In the case below,
> I have tried "int", "integer", "Integer" and "java.lang.Integer" and "Ljava.lang.Integer;"  for the type of parameter "region".
> <query name="com.tgcusa.idmgr.ProgramId.findProgramId">
>     <query-param name="region" type="integer"/>
>     <query-param name="epgser" type="string"/>
>     <query-param name="epgepi" type="string"/>
>     <![CDATA[
>       select pid.tgcsh, pid.tgcser, pid.tgcepi from com.tgcusa.idmgr.ProgramId
>       as pid where pid.region == :region and pid.epgser == :epgser and
>       pid.epgepi = :epgepi
>     ]]>
>   </query>
> The code generator always produces:
> public List findTgcSerForEpgSer(int region, java.lang.String tepgser)
>     {
>         Query query =
>             sessionFactory.getCurrentSession().getNamedQuery("com.tgcusa.idmgr.ProgramId.findTgcSerForEpgSer");
>         query.setParameter("region", region);
>         query.setParameter("tepgser", tepgser);
>         return query.list();
>     }
> Which has the compilation error:
>     [javac] Found 2 semantic errors compiling "/sandbox/mainline/srcroot/sw/tgcs
> vc/lib/java/src/com/tgcusa/idmgr/ProgramIdHome.java":
>     [javac]    171.         query.setParameter("region", region);
>     [javac]                 ^----------------------------------^
>     [javac] *** Semantic Error: No applicable overload for a method with signatu
> re "setParameter(java.lang.String, int)" was found in type "org.hibernate.Query"
> . Perhaps you wanted the overloaded version "org.hibernate.Query setParameter(ja
> va.lang.String $1, java.lang.Object $2) throws org.hibernate.HibernateException;
> " instead?
> It seems that:
> 1) There is ambiguity about the type "integer".  I have seen it generate java.lang.Integer in other  code.
> 2) for "int", a query.setParameter should support int.
> 3) for an Integer object, the setParameter call is ok, but the the method parameter shoud be Integer not int.

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (ANN-369) @CollectionOfElements on a Map uses reserved word "key" as column name

[Emmanuel B. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/ANN-369?page=comments#action_23570 ] 

Emmanuel Bernard commented on ANN-369:
--------------------------------------

Seems not to be clear to everyone, but you can set the column name through
@org.hibernate.annotations.MapKey

> @CollectionOfElements on a Map uses reserved word "key" as column name
> ----------------------------------------------------------------------
>
>          Key: ANN-369
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-369
>      Project: Hibernate Annotations
>         Type: Bug

>   Components: binder
>     Versions: 3.2.0.cr1
>  Environment: Hibernate 3.2.0cr1, MySQL 5
>     Reporter: Martin
>     Assignee: Emmanuel Bernard
>  Attachments: dont_use_key_for_maps.diff
>
>
> This annotation
> [User.java]
> @CollectionOfElements
> public Map<String, String> getMisc()
> results in this create table statement:
> create table User_misc (User_id bigint not null, element varchar(255), key varchar(255), primary key (User_id, key)) type=InnoDB
> But "KEY" is a reserved word, so MySQL won't create that table. The default column name should either change or be enclosed by backticks.

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira