hibernate-issues — Hibernate JIRA Notifications

[Hibernate-issues] [Hibernate-JIRA] Created: (EJB-178) JarVisitor.getVisitor does not treat correctly paths with spaces

[Alexandrino L. (JIRA) <no...@at...>]

JarVisitor.getVisitor does not treat correctly paths with spaces
----------------------------------------------------------------

         Key: EJB-178
         URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-178
     Project: Hibernate Entity Manager
        Type: Bug

  Components: EntityManager  
    Versions: 3.1.0.Beta8    
 Environment: Windows XP Professional; Tomcat 5.5.17.
    Reporter: Alexandrino Lucas


I'm using Hibernate Entity Manager with a WAR deployed on Tomcat 5.5.17, and I'm getting the following error:

11/05/2006 16:12:43 org.hibernate.ejb.packaging.FileZippedJarVisitor doProcessElements
WARNING: Unable to find file (ignored): file:/C:/Program%20Files/Apache%20Software%20Foundation/Tomcat%205.5/webapps/[REST OMITTED]
java.util.zip.ZipException: Access is denied
	at java.util.zip.ZipFile.open(Native Method)
	at java.util.zip.ZipFile.<init>(Unknown Source)
	at java.util.jar.JarFile.<init>(Unknown Source)
	at java.util.jar.JarFile.<init>(Unknown Source)
	at org.hibernate.ejb.packaging.FileZippedJarVisitor.doProcessElements(FileZippedJarVisitor.java:34)
	at org.hibernate.ejb.packaging.JarVisitor.getMatchingEntries(JarVisitor.java:208)
	at org.hibernate.ejb.Ejb3Configuration.addMetadataFromVisitor(Ejb3Configuration.java:201)
	at org.hibernate.ejb.Ejb3Configuration.createEntityManagerFactory(Ejb3Configuration.java:183)
	at org.hibernate.ejb.HibernatePersistence.createEntityManagerFactory(HibernatePersistence.java:114)
	at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:37)
  [MORE...]

Two strange things: 1) the directory exists; 2) Hibernate is treating the path as being part of a JAR file. I found the cause of the problem when analysing org.hibernate.ejb.packaging.JarVisitor.getVisitor(URL, Filter[]):

    File file = new File( jarUrl.getFile() );
    if ( file.isDirectory() ) {
        return new ExplodedJarVisitor( jarUrl, filters );
    }
    else {
        return new FileZippedJarVisitor( jarUrl, filters );
    }

As my path has some spaces, jarUrl.getFile() returns "/C:/Program%20Files/Apache%20Software%20Foundation/Tomcat%205.5/webapps/[REST OMITTED]", which is not a directory, because of the "%20"'s. The specification of the java.net.URL class says: "The URL class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL."

Although I did not have the time to build the project with it, I think that jarUrl.toURI().getPath() would solve the problem. Here is a snippet to prove it:

import java.io.File;
import java.net.URL;

public class Main
{
    public static void main(
        String[] args )
        throws Exception
    {
        URL url = new URL(
            "file:///C:/Program%20Files/Apache%20Software%20Foundation/Tomcat%205.5/webapps" );
        System.out.println( "url.getFile()" );
        System.out.println( url.getFile() );
        System.out.println( new File( url.getFile() ).isDirectory() );
        System.out.println();
        System.out.println();
        System.out.println();
        System.out.println( "url.toURI().getPath()" );
        System.out.println( url.toURI().getPath() );
        System.out.println( new File( url.toURI().getPath() ).isDirectory() );
    }
}


-- 
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-1744) BorrowedConnectionProxy does not support isClosed() operation

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

BorrowedConnectionProxy does not support isClosed() operation
-------------------------------------------------------------

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

  Components: core  
 Environment: hibernate 3.2.0.cr1, oracle9i
    Reporter: Roel Adriaensens


If you try to invoke the isClosed() method of a connection, the BorrowedConnectionProxy will call ConnectionManager.getConnection() which results in a HibernateException if the connection is closed.

stacktrace:
Caused by: org.hibernate.HibernateException: connection manager has been closed
	at org.hibernate.jdbc.ConnectionManager.getConnection(ConnectionManager.java:141)
	at org.hibernate.jdbc.BorrowedConnectionProxy.invoke(BorrowedConnectionProxy.java:40)
	at $Proxy131.isClosed(Unknown Source)
        ...

Relevant code (BorrowedConnectionProxy):

public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
		if ( "close".equals( method.getName() ) ) {
			connectionManager.releaseBorrowedConnection();
			return null;
		}
		// should probably no-op commit/rollback here, at least in JTA scenarios
		if ( !useable ) {
			throw new HibernateException( "connnection proxy not usable after transaction completion" );
		}
		try {
			return method.invoke( connectionManager.getConnection(), args );
		}
		catch( InvocationTargetException e ) {
			throw e.getTargetException();
		}
	}
      



-- 
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-341) EntityBinder is always auto-import

[Barry K. (JIRA) <no...@at...>]

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

Barry Kaplan commented on ANN-341:
----------------------------------

Yup, I missed it. Its right there in 8.1. Thanks Emmanuel.

> EntityBinder is always auto-import
> ----------------------------------
>
>          Key: ANN-341
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-341
>      Project: Hibernate Annotations
>         Type: Bug

>   Components: binder
>     Versions: 3.1.0.Beta10
>     Reporter: Barry Kaplan

>
>
> I have two classes with the same unqualified name but in different packages:
> package org.opentrader.foo;
> @Entity
> class Order { ... }
> package org.opentrader.bar;
> @Entity
> class Order { ... }
> These classes are added using AnnotationConfiguration.addAnnotatedClass(). 
> But when these classes are added, EntityBinder.bindEjb3Annotation will use the unqualified name as the key for storing the entity:
> class EntityBinder {
>     ...
>     if ( AnnotationBinder.isDefault( ejb3Ann.name() ) ) {
>         name = StringHelper.unqualify( annotatedClass.getName() );
>     }
>     else {
>         name = ejb3Ann.name();
>     }
>     ...
>     try {
>         mappings.addImport( persistentClass.getEntityName(), name );
>     }
>     catch (MappingException me) {
>         throw new AnnotationException( "Use of the same entity name twice: " + name );
>     }
> }
> class Mappings {
>     public void addImport(...) {
>         String existing = (String) imports.put(rename, className);
>     }
> }
> When HbmBinder adds imports, it has logic to /not/ add the class using its unqualified name:
> class HbmBinder.addImport() {
>     mappings.addImport( entity.getEntityName(), entity.getEntityName() );
>     if ( mappings.isAutoImport() && entity.getEntityName().indexOf( '.' ) > 0 ) {
>         mappings.addImport(
>                 entity.getEntityName(),
>                 StringHelper.unqualify( entity.getEntityName() )
>                 );
>     }
> }
> Should not EntityBinder also explicitly support auto-import?

-- 
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-1743) Wrong order of binding parameters in Restrictions.in for composite primary keys

[Viatcheslav (JIRA) <no...@at...>]

Wrong order of binding parameters in Restrictions.in for composite primary keys
-------------------------------------------------------------------------------

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

  Components: query-criteria  
    Versions: 3.2.0 cr1    
 Environment: Windows XP, Oracle 10g
    Reporter: Viatcheslav
 Attachments: HibernateTest_restrictions_in_parameter_binding.zip

There is a table Person with composite primary key:
PERSON
primary key fields:
  FAMILY
  NUMBER

For the Criteria Query like
		List<PersonId> ids = new Vector<PersonId>();
		ids.add(new PersonId("SLAVA1", 10L));
		ids.add(new PersonId("SLAVA2", 20L));
		ids.add(new PersonId("SLAVA3", 30L));
		List<Person> persons = session.createCriteria(Person.class)
			.add(Restrictions.in("id", ids))
			.list();

 the query  is generated
select this_.FAMILY as FAMILY0_0_, this_.NUMBER as NUMBER0_0_ from PERSON this_ where (this_.FAMILY, this_.NUMBER) in ((?, ?), (?, ?), (?, ?))

The query is right, but the parameters are bound in wrong order, here is the excerpt from the log:
16:21:33,221 DEBUG [SQL] select this_.FAMILY as FAMILY0_0_, this_.NUMBER as NUMBER0_0_ from PERSON this_ where (this_.FAMILY, this_.NUMBER) in ((?, ?), (?, ?), (?, ?))
Hibernate: select this_.FAMILY as FAMILY0_0_, this_.NUMBER as NUMBER0_0_ from PERSON this_ where (this_.FAMILY, this_.NUMBER) in ((?, ?), (?, ?), (?, ?))
16:21:33,221 DEBUG [AbstractBatcher] preparing statement
16:21:33,330 DEBUG [StringType] binding 'SLAVA1' to parameter: 1
16:21:33,330 DEBUG [StringType] binding 'SLAVA2' to parameter: 2
16:21:33,330 DEBUG [StringType] binding 'SLAVA3' to parameter: 3
16:21:33,330 DEBUG [LongType] binding '10' to parameter: 4
16:21:33,330 DEBUG [LongType] binding '20' to parameter: 5
16:21:33,330 DEBUG [LongType] binding '30' to parameter: 6


I've made an example (attached, standalone eclipse project with all libs) which demonstrates the problem, but you need running oracle somewhere to run it. See also bug report HH-708 which is predecessor of this.

The problem may lay in org.hibernate.criterion.InExpression::getTypedValues.

Instead of 

for ( int i=0; i<types.length; i++ ) { 
for ( int j=0; j<values.length; j++ ) { 
Object subval = values[j]==null ? 
null : 
actype.getPropertyValues( values[j], EntityMode.POJO )[i]; 
list.add( new TypedValue( types[i], subval, EntityMode.POJO ) ); 
} 
} 


should be 

for ( int j=0; j<values.length; j++ ) { 
for ( int i=0; i<types.length; i++ ) { 
Object subval = values[j]==null ? 
null : 
actype.getPropertyValues( values[j], EntityMode.POJO )[i]; 
list.add( new TypedValue( types[i], subval, EntityMode.POJO ) ); 
} 
} 


After change have worked for me. But I am not sure whether the syntax of what's going from Restriction.in is database-specific.


-- 
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-341) EntityBinder is always auto-import

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

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

Emmanuel Bernard commented on ANN-341:
--------------------------------------

Stated in the spec PDF Chapter 8.1 in my version.
either use a fqcn in your @Entity(name) or use XML to override the mapping


> EntityBinder is always auto-import
> ----------------------------------
>
>          Key: ANN-341
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-341
>      Project: Hibernate Annotations
>         Type: Bug

>   Components: binder
>     Versions: 3.1.0.Beta10
>     Reporter: Barry Kaplan

>
>
> I have two classes with the same unqualified name but in different packages:
> package org.opentrader.foo;
> @Entity
> class Order { ... }
> package org.opentrader.bar;
> @Entity
> class Order { ... }
> These classes are added using AnnotationConfiguration.addAnnotatedClass(). 
> But when these classes are added, EntityBinder.bindEjb3Annotation will use the unqualified name as the key for storing the entity:
> class EntityBinder {
>     ...
>     if ( AnnotationBinder.isDefault( ejb3Ann.name() ) ) {
>         name = StringHelper.unqualify( annotatedClass.getName() );
>     }
>     else {
>         name = ejb3Ann.name();
>     }
>     ...
>     try {
>         mappings.addImport( persistentClass.getEntityName(), name );
>     }
>     catch (MappingException me) {
>         throw new AnnotationException( "Use of the same entity name twice: " + name );
>     }
> }
> class Mappings {
>     public void addImport(...) {
>         String existing = (String) imports.put(rename, className);
>     }
> }
> When HbmBinder adds imports, it has logic to /not/ add the class using its unqualified name:
> class HbmBinder.addImport() {
>     mappings.addImport( entity.getEntityName(), entity.getEntityName() );
>     if ( mappings.isAutoImport() && entity.getEntityName().indexOf( '.' ) > 0 ) {
>         mappings.addImport(
>                 entity.getEntityName(),
>                 StringHelper.unqualify( entity.getEntityName() )
>                 );
>     }
> }
> Should not EntityBinder also explicitly support auto-import?

-- 
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-1742) SQL join is missed in Criteria queries for join/alias on foreign key as part of composite primary key (many-to-one association)

[Viatcheslav (JIRA) <no...@at...>]

SQL join is missed in Criteria queries for join/alias on foreign key as part of composite primary key (many-to-one association)
-------------------------------------------------------------------------------------------------------------------------------

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

  Components: query-criteria  
    Versions: 3.2.0 cr1    
 Environment: Windows XP, Oracle 10g, HSQLDB
    Reporter: Viatcheslav
 Attachments: HibernateTest.zip

I've stuck with Criteria API on issue, that the join is sometimes missed from generated SQL query doing joining on foreign key.

Here is the little example I've made to demonstrate the problem (also attached as standalone runnable eclipse project)

There are two tables:
FAMILY
familyName as primary key
familyProperty

PERSON
familyName as foreign key on FAMILY   } the both fields make primary key 
personName                                               } of PERSON

Doing query on person like
session.createCriteria(Person.class)
     .createCriteria("id.family")
     .add(Restrictions.eq("familyProperty", "whatever"))
     .list();

Causes query 
Hibernate: select this_.FAMILY_NAME as FAMILY1_1_0_, this_.PERSON_NAME as PERSON2_1_0_ from PERSON this_ where family1_.FAMILY_PROPERTY=?
.. which is rather invalid

The same by the way happens doing query 
session.createCriteria(Person.class)
     .createCriteria("id.family")
     .add(Restrictions.eq("familyName", "whatever"))
     .list();

The query 
select this_.FAMILY_NAME as FAMILY1_1_0_, this_.PERSON_NAME as PERSON2_1_0_ from PERSON this_ where family1_.FAMILY_NAME=?
.. is invalid either though it can be made valid without join, because family1_.FAMILY_NAME can be accessed through this_.FAMILY_NAME

The attachment is a whole eclipse project, pretty straightforward, with hsqldb, which demonstrates the SQL generated and the problem.

I suspect this bug may be caused by the fix to HH-528 (component.manyToOne.id in HQL causes join).

The priority should be high because
session.createCriteria(Person.class)
	.createAlias("id.family", "family")
	.add(Restrictions.eq("family.familyProperty", "whatever"))
	.list();
doesn't work either. 
In effect there is no way to cause join on foreign key with Criteria API. Whatever in hibernate blocks join on foreign key rather zealous.


-- 
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-341) EntityBinder is always auto-import

[Barry K. (JIRA) <no...@at...>]

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

Barry Kaplan commented on ANN-341:
----------------------------------

I could not find anything in the spec which states the default value for 'name' /must/ be the unqualified class name? Did I just miss it? Or is this is a hibernate specific decision?

Do you know how it is recommended to handle the case when a product is including two thirdparty jars with conflicting unqualified @Entity's where changing the source is not an option? This is the case that I am concerned about wrt this issue. 

> EntityBinder is always auto-import
> ----------------------------------
>
>          Key: ANN-341
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-341
>      Project: Hibernate Annotations
>         Type: Bug

>   Components: binder
>     Versions: 3.1.0.Beta10
>     Reporter: Barry Kaplan

>
>
> I have two classes with the same unqualified name but in different packages:
> package org.opentrader.foo;
> @Entity
> class Order { ... }
> package org.opentrader.bar;
> @Entity
> class Order { ... }
> These classes are added using AnnotationConfiguration.addAnnotatedClass(). 
> But when these classes are added, EntityBinder.bindEjb3Annotation will use the unqualified name as the key for storing the entity:
> class EntityBinder {
>     ...
>     if ( AnnotationBinder.isDefault( ejb3Ann.name() ) ) {
>         name = StringHelper.unqualify( annotatedClass.getName() );
>     }
>     else {
>         name = ejb3Ann.name();
>     }
>     ...
>     try {
>         mappings.addImport( persistentClass.getEntityName(), name );
>     }
>     catch (MappingException me) {
>         throw new AnnotationException( "Use of the same entity name twice: " + name );
>     }
> }
> class Mappings {
>     public void addImport(...) {
>         String existing = (String) imports.put(rename, className);
>     }
> }
> When HbmBinder adds imports, it has logic to /not/ add the class using its unqualified name:
> class HbmBinder.addImport() {
>     mappings.addImport( entity.getEntityName(), entity.getEntityName() );
>     if ( mappings.isAutoImport() && entity.getEntityName().indexOf( '.' ) > 0 ) {
>         mappings.addImport(
>                 entity.getEntityName(),
>                 StringHelper.unqualify( entity.getEntityName() )
>                 );
>     }
> }
> Should not EntityBinder also explicitly support auto-import?

-- 
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-708) Restrictions.in could not be used properly on composite-ids

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

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

Max Rydahl Andersen commented on HHH-708:
-----------------------------------------

open a new issue and add a *patch* and a test that show it fails.

> Restrictions.in could not be used properly on composite-ids
> -----------------------------------------------------------
>
>          Key: HHH-708
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-708
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.0.5
>  Environment: Oracle 9i, org.hibernate.criterion.InExpression
>     Reporter: Holger Bartnick
>      Fix For: 3.1 beta 1

>
>
> Restrictions.in could not be used properly on composite-ids
> for a composite-id with the attributes key and station
> the resulting sql is like: 
>   [where key in (?,?...) and station in (?,?...)]
> it should result in an sql like: 
>   [where (key, station) in ((?,?),(?,?)...)]
> otherwise the result would be a scalar product 
> example:
> key       station
> 1         1
> 2         1
> 2         2
> 3         2
> [where key in (1,2,3) and station in (1,2)]
> would return all values
> [where (key, station) in ((1,1),(2,1),(3,2))]
> would omit the record (2,2)

-- 
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-708) Restrictions.in could not be used properly on composite-ids

[Viatcheslav (JIRA) <no...@at...>]

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

Viatcheslav commented on HHH-708:
---------------------------------

Agree, have this issue too.

As quick shot the loop order in org.hibernate.criterion.InExpression::getTypedValues is wrong
instead of 

			for ( int i=0; i<types.length; i++ ) {
				for ( int j=0; j<values.length; j++ ) {
					Object subval = values[j]==null ? 
						null : 
						actype.getPropertyValues( values[j], EntityMode.POJO )[i];
					list.add( new TypedValue( types[i], subval, EntityMode.POJO ) );
				}
			}


it should be 

			for ( int j=0; j<values.length; j++ ) {
				for ( int i=0; i<types.length; i++ ) {
					Object subval = values[j]==null ? 
						null : 
						actype.getPropertyValues( values[j], EntityMode.POJO )[i];
					list.add( new TypedValue( types[i], subval, EntityMode.POJO ) );
				}
			}


After change have worked for me.

This bug is marked as closed, maybe new one should be opened or this reopened, otherwise I'm afraid the developers will not see the issue.

> Restrictions.in could not be used properly on composite-ids
> -----------------------------------------------------------
>
>          Key: HHH-708
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-708
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.0.5
>  Environment: Oracle 9i, org.hibernate.criterion.InExpression
>     Reporter: Holger Bartnick
>      Fix For: 3.1 beta 1

>
>
> Restrictions.in could not be used properly on composite-ids
> for a composite-id with the attributes key and station
> the resulting sql is like: 
>   [where key in (?,?...) and station in (?,?...)]
> it should result in an sql like: 
>   [where (key, station) in ((?,?),(?,?)...)]
> otherwise the result would be a scalar product 
> example:
> key       station
> 1         1
> 2         1
> 2         2
> 3         2
> [where key in (1,2,3) and station in (1,2)]
> would return all values
> [where (key, station) in ((1,1),(2,1),(3,2))]
> would omit the record (2,2)

-- 
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: (HHH-1547) Query syntax error using IdentifierProjection.toSqlString()

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

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

    Resolution: Duplicate

> Query syntax error using IdentifierProjection.toSqlString()
> -----------------------------------------------------------
>
>          Key: HHH-1547
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1547
>      Project: Hibernate3
>         Type: Bug

>   Components: query-criteria
>     Versions: 3.1.2
>  Environment: Hibernate 3.1.2
> Oracle Database 10g Release 1
>     Reporter: Georgios Skempes
>     Priority: Minor

>
>
> While using IdentifierProjection.toSqlString() with a composite id, I got above wrong SQL syntax because of a bug. I modified the source of hibernate as follows:
> Original:
> ------------------------------------------------------
> package org.hibernate.criterion;
> ...
> public class IdentifierProjection extends SimpleProjection {
> ...
> 	public String toSqlString(Criteria criteria, int position, CriteriaQuery criteriaQuery) 
> 	throws HibernateException {
> 		StringBuffer buf = new StringBuffer();
> 		String[] cols = criteriaQuery.getIdentifierColumns(criteria);
> 		for ( int i=0; i<cols.length; i++ ) {
> 			buf.append( cols[i] )
> 				.append(" as y")
> 				.append(position + i)
> 				.append("_");
> 		}
> 		return buf.toString();
> 	}
> }
> My Modification:
> -------------------------------------
> package org.hibernate.criterion;
> ...
> public class IdentifierProjection extends SimpleProjection {
> ...
> 	public String toSqlString(Criteria criteria, int position, CriteriaQuery criteriaQuery) 
> 	throws HibernateException {
> 		StringBuffer buf = new StringBuffer();
> 		String[] cols = criteriaQuery.getIdentifierColumns(criteria);
> 		for ( int i=0; i<cols.length; i++ ) {
> 			buf.append( cols[i] )
> 				.append(" as y")
> 				.append(position + i)
> 				.append("_, ");
> 		}
> 		buf.delete(buf.length() - 2, buf.length());
> 		return buf.toString();
> 	}
> }
> The generated SQL (show_sql=true):
> select address0_.PAR_ID as col_0_0_address0_.NUM as col_1_0_, ...

-- 
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-1088) IdentifierProjection does not work with composite keys

[Viatcheslav (JIRA) <no...@at...>]

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

Viatcheslav commented on HHH-1088:
----------------------------------

HH-1547is the same reported.
I'd raise the priority of the bug because of many users affected.

> IdentifierProjection does not work with composite keys
> ------------------------------------------------------
>
>          Key: HHH-1088
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1088
>      Project: Hibernate3
>         Type: Bug

>     Versions: 3.1 rc2
>     Reporter: Max Muermann
>     Priority: Minor

>
>
> When working with Criteria queries, the IdentifierProjection breaks if the entity has a composite key.
> In IdentifierProjection.java:
> public String toSqlString(Criteria criteria, int position, CriteriaQuery criteriaQuery) 
> 	throws HibernateException {
> 		StringBuffer buf = new StringBuffer();
> 		String[] cols = criteriaQuery.getIdentifierColumns(criteria);
> 		for ( int i=0; i<cols.length; i++ ) {
> 			buf.append( cols[i] )
> 				.append(" as y")
> 				.append(position + i)
> 				.append('_');
> 		}
> 		return buf.toString();
> 	}
> This method does not add commas as separators between the column names. Easily fixed by adding
> if (i<col.length-1)
>   buf.append(",");
> as the last statement inside the loop.
> However, this leads to another problem:
> the type returned by IdentifierProjection.geType is the (single) type of the composite id component. The query will however return the property values of the id component without a mapping step.

-- 
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-1547) Query syntax error using IdentifierProjection.toSqlString()

[Viatcheslav (JIRA) <no...@at...>]

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

Viatcheslav commented on HHH-1547:
----------------------------------

The same problem is reported in HH-1088

> Query syntax error using IdentifierProjection.toSqlString()
> -----------------------------------------------------------
>
>          Key: HHH-1547
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1547
>      Project: Hibernate3
>         Type: Bug

>   Components: query-criteria
>     Versions: 3.1.2
>  Environment: Hibernate 3.1.2
> Oracle Database 10g Release 1
>     Reporter: Georgios Skempes
>     Priority: Minor

>
>
> While using IdentifierProjection.toSqlString() with a composite id, I got above wrong SQL syntax because of a bug. I modified the source of hibernate as follows:
> Original:
> ------------------------------------------------------
> package org.hibernate.criterion;
> ...
> public class IdentifierProjection extends SimpleProjection {
> ...
> 	public String toSqlString(Criteria criteria, int position, CriteriaQuery criteriaQuery) 
> 	throws HibernateException {
> 		StringBuffer buf = new StringBuffer();
> 		String[] cols = criteriaQuery.getIdentifierColumns(criteria);
> 		for ( int i=0; i<cols.length; i++ ) {
> 			buf.append( cols[i] )
> 				.append(" as y")
> 				.append(position + i)
> 				.append("_");
> 		}
> 		return buf.toString();
> 	}
> }
> My Modification:
> -------------------------------------
> package org.hibernate.criterion;
> ...
> public class IdentifierProjection extends SimpleProjection {
> ...
> 	public String toSqlString(Criteria criteria, int position, CriteriaQuery criteriaQuery) 
> 	throws HibernateException {
> 		StringBuffer buf = new StringBuffer();
> 		String[] cols = criteriaQuery.getIdentifierColumns(criteria);
> 		for ( int i=0; i<cols.length; i++ ) {
> 			buf.append( cols[i] )
> 				.append(" as y")
> 				.append(position + i)
> 				.append("_, ");
> 		}
> 		buf.delete(buf.length() - 2, buf.length());
> 		return buf.toString();
> 	}
> }
> The generated SQL (show_sql=true):
> select address0_.PAR_ID as col_0_0_address0_.NUM as col_1_0_, ...

-- 
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-333) QuerySyntaxError when using JOIN index(...) in HQL query

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

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

Etienne Bernard commented on HHH-333:
-------------------------------------

Just so that everyone knows...

FROM test.A AS a JOIN a.abs AS ab JOIN index(ab) AS b WHERE ab.status=1

can be replaced with the syntax :

FROM test.A AS a JOIN a.abs AS ab JOIN ab.index AS b WHERE ab.status=1

which works perfectly with Hibernate 3.0 and 3.1.

This features seems to not be documented. I'm not sure if it's wanted or not but for me it's the only way to perform complex HQL queries involving many-to-many relationships.

> QuerySyntaxError when using JOIN index(...) in HQL query
> --------------------------------------------------------
>
>          Key: HHH-333
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-333
>      Project: Hibernate3
>         Type: Bug

>   Components: query-hql
>     Versions: 3.0 final
>     Reporter: Etienne Bernard
>     Priority: Minor

>
>
> I've been using this syntax since hibernate 2.0 :
> FROM test.A AS a JOIN a.abs AS ab JOIN index(ab) AS b WHERE ab.status=1
> with the following mapping :
> [...]
>     <class name="test.A" table="a">
> [...]
>         <map name="abs" table="ab" lazy="true">
>               <key column="a"></key>
>               <index-many-to-many class="test.B" column="b"/>
>               <composite-element class="test.AB">
>                   <property name="status" type="int"/>
>               </composite-element>
>         </map>
> [...]
>     </class>
> [...]
> It used to work with hibernate 2.1 too. It doesn't work anymore with hibernate 3.0 final.
> See the attached example for a complete test case.
> Thanks.

-- 
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-658) table-filter package should take effect on default table class names

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

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

    Fix Version: 3.2beta6
     Resolution: Fixed

implemented

> table-filter package should take effect on default table class names
> --------------------------------------------------------------------
>
>          Key: HBX-658
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-658
>      Project: Hibernate Tools
>         Type: New Feature

>   Components: reverse-engineer
>     Reporter: Max Rydahl Andersen
>      Fix For: 3.2beta6

>
>
> <table-filter match=".*" package="hello">
> <table name="X" class="MyX">
> should result in hello.MyX, currently it assumes default package.

-- 
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-1741) Bug in reference documentation

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

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

Christian Bauer updated HHH-1741:
---------------------------------

      Version: 3.2.0.cr2
                   (was: 3.2.1)
                   (was: 3.1.4)
                   (was: 3.2.0)
                   (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.2.0.alpha1)
    Assign To: Christian Bauer
     Priority: Trivial  (was: Major)

> Bug in reference documentation
> ------------------------------
>
>          Key: HHH-1741
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1741
>      Project: Hibernate3
>         Type: Bug

>   Components: documentation
>     Versions: 3.2.0.cr2
>     Reporter: Luca Masini
>     Assignee: Christian Bauer
>     Priority: Trivial

>
> Original Estimate: 1 minute
>         Remaining: 1 minute
>
> From paragraph 1.4.1:
> "1.4.1. Writing the basic servlet
> Create a new class in your source directory, in the events package:
> package events;
> // Imports
> public class EventManagerServlet extends HttpServlet {
> private final SimpleDateFormat dateFormatter =
> new SimpleDateFormat("dd.MM.yyyy");
> // Servlet code
> }
> The dateFormatter is a tool we'll need later to convert Date objects from and to strings. It makes sense to only
> have one formatter as a member of the servlet."
> but if you read the JDK 1.4 and later Javadocs there is a note at the bottom of the description of the SimpleDateFormat class:
> "Synchronization
> Date formats are not synchronized. It is recommended to create separate format instances for each thread. If multiple threads access a format concurrently, it must be synchronized externally. "
> This mean that the example is buggy and will not work if two thread use the same servlet at the same time. Please correct it putting the dateFormatter instantiation into the doGet 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-1741) Bug in reference documentation

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

Bug in reference documentation
------------------------------

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

  Components: documentation  
    Versions: 3.2.1, 3.1.4, 3.2.0, 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.2.0.alpha1    
    Reporter: Luca Masini


From paragraph 1.4.1:

"1.4.1. Writing the basic servlet
Create a new class in your source directory, in the events package:
package events;
// Imports
public class EventManagerServlet extends HttpServlet {
private final SimpleDateFormat dateFormatter =
new SimpleDateFormat("dd.MM.yyyy");
// Servlet code
}
The dateFormatter is a tool we'll need later to convert Date objects from and to strings. It makes sense to only
have one formatter as a member of the servlet."

but if you read the JDK 1.4 and later Javadocs there is a note at the bottom of the description of the SimpleDateFormat class:
"Synchronization

Date formats are not synchronized. It is recommended to create separate format instances for each thread. If multiple threads access a format concurrently, it must be synchronized externally. "

This mean that the example is buggy and will not work if two thread use the same servlet at the same time. Please correct it putting the dateFormatter instantiation into the doGet 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: (HBX-658) table-filter package should take effect on default table class names

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

table-filter package should take effect on default table class names
--------------------------------------------------------------------

         Key: HBX-658
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-658
     Project: Hibernate Tools
        Type: New Feature

  Components: reverse-engineer  
    Reporter: Max Rydahl Andersen



<table-filter match=".*" package="hello">

<table name="X" class="MyX">

should result in hello.MyX, currently it assumes default package.

-- 
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-657) improve foreign key constraint name docs and inverse generation

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

improve foreign key constraint name docs and inverse generation
---------------------------------------------------------------

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

    Versions: 3.1.beta5    
    Reporter: Max Rydahl Andersen


<foreign-key constraint-name/>
 
Documentation for the constraint-name attribute has to be improved. What exactly is this? Is it something that comes from the database (I know it is)? The 
foreign key constraint name is not generated/included in the <many-to-one> column or the collection key column in the hbm.xml file. The set is 
inverse="true", even if <many-to-one> is excluded.

-- 
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] Resolved: (EJB-177) in beforeCompletion phase, the transaction might not be returned causing an NPE

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

     [ http://opensource.atlassian.com/projects/hibernate/browse/EJB-177?page=all ]
     
Emmanuel Bernard resolved EJB-177:
----------------------------------

    Resolution: Fixed

> in beforeCompletion phase, the transaction might not be returned causing an NPE
> -------------------------------------------------------------------------------
>
>          Key: EJB-177
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-177
>      Project: Hibernate Entity Manager
>         Type: Bug

>   Components: EntityManager
>     Reporter: Emmanuel Bernard
>     Assignee: Emmanuel Bernard
>      Fix For: 3.2.0.cr1

>
>


-- 
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: (EJB-177) in beforeCompletion phase, the transaction might not be returned causing an NPE

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

in beforeCompletion phase, the transaction might not be returned causing an NPE
-------------------------------------------------------------------------------

         Key: EJB-177
         URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-177
     Project: Hibernate Entity Manager
        Type: Bug

  Components: EntityManager  
    Reporter: Emmanuel Bernard
 Assigned to: Emmanuel Bernard 
     Fix For: 3.2.0.cr1




-- 
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] Resolved: (ANN-341) EntityBinder is always auto-import

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

     [ http://opensource.atlassian.com/projects/hibernate/browse/ANN-341?page=all ]
     
Emmanuel Bernard resolved ANN-341:
----------------------------------

    Resolution: Rejected

as per the spec use @entity(name="myuniquename")

> EntityBinder is always auto-import
> ----------------------------------
>
>          Key: ANN-341
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-341
>      Project: Hibernate Annotations
>         Type: Bug

>   Components: binder
>     Versions: 3.1.0.Beta10
>     Reporter: Barry Kaplan

>
>
> I have two classes with the same unqualified name but in different packages:
> package org.opentrader.foo;
> @Entity
> class Order { ... }
> package org.opentrader.bar;
> @Entity
> class Order { ... }
> These classes are added using AnnotationConfiguration.addAnnotatedClass(). 
> But when these classes are added, EntityBinder.bindEjb3Annotation will use the unqualified name as the key for storing the entity:
> class EntityBinder {
>     ...
>     if ( AnnotationBinder.isDefault( ejb3Ann.name() ) ) {
>         name = StringHelper.unqualify( annotatedClass.getName() );
>     }
>     else {
>         name = ejb3Ann.name();
>     }
>     ...
>     try {
>         mappings.addImport( persistentClass.getEntityName(), name );
>     }
>     catch (MappingException me) {
>         throw new AnnotationException( "Use of the same entity name twice: " + name );
>     }
> }
> class Mappings {
>     public void addImport(...) {
>         String existing = (String) imports.put(rename, className);
>     }
> }
> When HbmBinder adds imports, it has logic to /not/ add the class using its unqualified name:
> class HbmBinder.addImport() {
>     mappings.addImport( entity.getEntityName(), entity.getEntityName() );
>     if ( mappings.isAutoImport() && entity.getEntityName().indexOf( '.' ) > 0 ) {
>         mappings.addImport(
>                 entity.getEntityName(),
>                 StringHelper.unqualify( entity.getEntityName() )
>                 );
>     }
> }
> Should not EntityBinder also explicitly support auto-import?

-- 
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-1739) HILO id can cause deadlock: Part deux

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

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

Emmanuel Bernard commented on HHH-1739:
---------------------------------------

note that if for some reason on a given session you must initialize the hi value for each entity type of a motley object gragh, 2 connections are used conccurrently, not more.

> HILO id can cause deadlock: Part deux
> -------------------------------------
>
>          Key: HHH-1739
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1739
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.1.3
>  Environment: Hibernate 3.1.3 running JDK 1.4.1_07 Solaris 5.8
> Adaptive Server Enterprise/12.5.2/EBF 12054 ESD#2/P/Sun_svr4/OS 5.8/ase1252/1844/64-bit/FBO/Thu Aug 12 10:51:11 2004
>     Reporter: Kirk Rasmussen

>
> Original Estimate: 1 minute
>         Remaining: 1 minute
>
> This is mostly a duplicate of HB-1246 but with a twist. I believe that there is a flaw in Hibernate's design for how it generates ids for some dialects. This is a particular problem for deep object graphs and/or at high volume. Or at least it is a problem for those of us stuck on the crappy Sybase platform.
> We have an application that creates hundreds of objects that need ids generated within a single transaction. It is quite common for us to potentially exhaust the connection pool with a deep object graph. We are persisting a Trade object which has a complex and deep object graph (upwards of 100s of persistent objects). Within each trade there are roughly 15 classes which need generated ids with 30 or more instances of each class in some cases. 
> IMO The design flaw is when the ids are generated. From quickly browsing the source it seems that they are being generated on the fly as the objects are being processed. This can result in running of out database connections when under load or when a particular trade has a large number of persistent object instances and deadlocking the system.
> A better design would be if the ids could be generated for all tables in a single transaction up front rather than issuing a whole bunch of individual transactions for each table and object. 
> I believe that TOPLink generates all its ids up front to avoid the described resource thrashing. It also has the configuration to generate ids from within the same transaction as the original unit of work or from a secondary unit of work.
> See org.hibernate.id.MultipleHiLoPerTableGenerator 

-- 
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-1739) HILO id can cause deadlock: Part deux

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

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

Emmanuel Bernard commented on HHH-1739:
---------------------------------------

The TL solution does not work since the hi value has to be read/set in DB every max_lo id generation, this is of course not synchronized for all hilo generators.
A way to reduce the starving is to have a max-lo value high enough.

> HILO id can cause deadlock: Part deux
> -------------------------------------
>
>          Key: HHH-1739
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1739
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.1.3
>  Environment: Hibernate 3.1.3 running JDK 1.4.1_07 Solaris 5.8
> Adaptive Server Enterprise/12.5.2/EBF 12054 ESD#2/P/Sun_svr4/OS 5.8/ase1252/1844/64-bit/FBO/Thu Aug 12 10:51:11 2004
>     Reporter: Kirk Rasmussen

>
> Original Estimate: 1 minute
>         Remaining: 1 minute
>
> This is mostly a duplicate of HB-1246 but with a twist. I believe that there is a flaw in Hibernate's design for how it generates ids for some dialects. This is a particular problem for deep object graphs and/or at high volume. Or at least it is a problem for those of us stuck on the crappy Sybase platform.
> We have an application that creates hundreds of objects that need ids generated within a single transaction. It is quite common for us to potentially exhaust the connection pool with a deep object graph. We are persisting a Trade object which has a complex and deep object graph (upwards of 100s of persistent objects). Within each trade there are roughly 15 classes which need generated ids with 30 or more instances of each class in some cases. 
> IMO The design flaw is when the ids are generated. From quickly browsing the source it seems that they are being generated on the fly as the objects are being processed. This can result in running of out database connections when under load or when a particular trade has a large number of persistent object instances and deadlocking the system.
> A better design would be if the ids could be generated for all tables in a single transaction up front rather than issuing a whole bunch of individual transactions for each table and object. 
> I believe that TOPLink generates all its ids up front to avoid the described resource thrashing. It also has the configuration to generate ids from within the same transaction as the original unit of work or from a secondary unit of work.
> See org.hibernate.id.MultipleHiLoPerTableGenerator 

-- 
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: (ANN-341) EntityBinder is always auto-import

[Barry K. (JIRA) <no...@at...>]

EntityBinder is always auto-import
----------------------------------

         Key: ANN-341
         URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-341
     Project: Hibernate Annotations
        Type: Bug

  Components: binder  
    Versions: 3.1.0.Beta10    
    Reporter: Barry Kaplan


I have two classes with the same unqualified name but in different packages:

package org.opentrader.foo;
@Entity
class Order { ... }

package org.opentrader.bar;
@Entity
class Order { ... }

These classes are added using AnnotationConfiguration.addAnnotatedClass(). 

But when these classes are added, EntityBinder.bindEjb3Annotation will use the unqualified name as the key for storing the entity:

class EntityBinder {
    ...
    if ( AnnotationBinder.isDefault( ejb3Ann.name() ) ) {
        name = StringHelper.unqualify( annotatedClass.getName() );
    }
    else {
        name = ejb3Ann.name();
    }

    ...

    try {
        mappings.addImport( persistentClass.getEntityName(), name );
    }
    catch (MappingException me) {
        throw new AnnotationException( "Use of the same entity name twice: " + name );
    }
}

class Mappings {
    public void addImport(...) {
        String existing = (String) imports.put(rename, className);
    }
}

When HbmBinder adds imports, it has logic to /not/ add the class using its unqualified name:

class HbmBinder.addImport() {
    mappings.addImport( entity.getEntityName(), entity.getEntityName() );
    if ( mappings.isAutoImport() && entity.getEntityName().indexOf( '.' ) > 0 ) {
        mappings.addImport(
                entity.getEntityName(),
                StringHelper.unqualify( entity.getEntityName() )
                );
    }
}

Should not EntityBinder also explicitly support auto-import?

-- 
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-1740) Build-time instrumentation breaks lazy="proxy"

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

Build-time instrumentation breaks lazy="proxy"
----------------------------------------------

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

  Components: core  
    Versions: 3.1.3, 3.2.0 cr1, 3.2.0.cr2    
    Reporter: Frank Grimes
    Priority: Critical


I have a mapping that contains a many-to-one lazy="proxy".
This alone works fine: I see $$EnhancerByCGLIB$$ as the type when I do a load

Once I add a lazy property to the mapping and do build-time cglib enhancement, it breaks.
Not only is the lazy property listed in $CGLIB_READ_WRITE_CALLBACK, but also my lazy="proxy" association. (i.e. no more proxy object)

This works fine in hibernate-3.1.2.

This was originally brought up here: http://forums.hibernate.org/viewtopic.php?t=958881

Please let me know if more info or a test case is needed.

-- 
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