hibernate-issues — Hibernate JIRA Notifications

[Hibernate-issues] [Hibernate-JIRA] Created: (HB-163) Table locking

[<leg...@at...>]

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-163


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-163
    Summary: Table locking
       Type: New Feature

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
   Versions:
             2.0.1

   Assignee: 
   Reporter: Andrea Aime

    Created: Fri, 27 Jun 2003 2:42 AM
    Updated: Fri, 27 Jun 2003 2:42 AM

Description:
I would like to have a way to lock objects in a more database
independent way, and in  particular to lock a table. Now I need
to make it impossible for two instances of my client application
to perform a long task in parallel, but the present locking doesn't
work with databases that does not provide a "select for update".
On the other side, I guess that most databases provide table level
locking "LOCK TABLE ...". I would be a nice to have, currently I have
to isolate databases that don't support Hibernate locking and do my
own...
Oh, in the case of SapDb the locking problem could be solved by
using a row level lock (available) instead of a select for update.


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HBI-6) ClassCastException when using query.iterate() but works with query.list().iterator()

[<leg...@at...>]

The following comment has been added to this issue:

     Author: Noel Kee
    Created: Thu, 26 Jun 2003 10:02 PM
       Body:
How do I re-upload the file? Can't seem to find the link to do that.
---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HBI-6


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HBI-6
    Summary: ClassCastException when using query.iterate() but works with query.list().iterator()
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Hibernate 1.2

   Assignee: 
   Reporter: Noel Kee

    Created: Sun, 22 Jun 2003 4:07 AM
    Updated: Sun, 22 Jun 2003 4:08 AM
Environment: Mandrake Linux 9.1,
DB2 V7.2,
Sun's J2SDK 1.4.1_02,
Hibernate 1.2.4 (same situation with Hibernate 1.2.5)

Description:
A simple query, "from c in class itr.Product" throws a ClassCastException" when used with query.iterate(). If query.list().iterator() is used instead, it works fine.

The ClassCastException occured, when hibernate attempts to retrieve an associated class in the (itr.Pricing) in a bag and tries to cast the bag to a Long.

The complete set of java source, mapping and ddl is attached.


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HBI-6) ClassCastException when using query.iterate() but works with query.list().iterator()

[<leg...@at...>]

The following comment has been added to this issue:

     Author: Leonardo Bueno
    Created: Thu, 26 Jun 2003 5:02 PM
       Body:
I wasn't able to download the test case files... error 404
---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HBI-6


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HBI-6
    Summary: ClassCastException when using query.iterate() but works with query.list().iterator()
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Hibernate 1.2

   Assignee: 
   Reporter: Noel Kee

    Created: Sun, 22 Jun 2003 4:07 AM
    Updated: Sun, 22 Jun 2003 4:08 AM
Environment: Mandrake Linux 9.1,
DB2 V7.2,
Sun's J2SDK 1.4.1_02,
Hibernate 1.2.4 (same situation with Hibernate 1.2.5)

Description:
A simple query, "from c in class itr.Product" throws a ClassCastException" when used with query.iterate(). If query.list().iterator() is used instead, it works fine.

The ClassCastException occured, when hibernate attempts to retrieve an associated class in the (itr.Pricing) in a bag and tries to cast the bag to a Long.

The complete set of java source, mapping and ddl is attached.


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HB-162) No way to reset the maxResults() on a Query

[<leg...@at...>]

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-162


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-162
    Summary: No way to reset the maxResults() on a Query
       Type: Bug

     Status: Unassigned
   Priority: Minor

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0.1

   Assignee: 
   Reporter: Dawson M. Schaffer

    Created: Thu, 26 Jun 2003 12:39 PM
    Updated: Thu, 26 Jun 2003 12:39 PM

Description:
There is currently no way to reset the maximum number of results (query.setMaxResults(int)) returned from a Query once it has been set to a value.  While you can certainly set it to Integer.MAX_VALUE, that seems impractical.  I have tried query.setMaxResults(0) which produces "zero" results, and query.setMaxResults(-1) which produces an exception.

I have looked at the source code and noticed that internally the value is maintained as an Integer and initially starts as "null", however they current interface provides no mechanism to reset the value to "null" as the calling signature is as show above Query.setMaxResults(int).

My suggestion would be to simply take any value < 1 as a reset.

Cheers, Dawson



---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HB-161) sql-type is ignored by net.sf.hibernate.tool.hbm2ddl.SchemaExport

[<leg...@at...>]

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-161


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-161
    Summary: sql-type is ignored by net.sf.hibernate.tool.hbm2ddl.SchemaExport
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
   Versions:
             2.0.1

   Assignee: 
   Reporter: Frank Buss

    Created: Thu, 26 Jun 2003 8:45 AM
    Updated: Thu, 26 Jun 2003 8:45 AM

Description:
I've tried this in a hbm:

<property name="description" column="description" type="string">
	<column name="description" sql-type="text" />
</property>

but the SchemaExport generates this in the DDL:

description VARCHAR(255)



---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HB-145) insert for classes with composite-id crashes

[<leg...@at...>]

The following comment has been added to this issue:

     Author: Hrituc Ovidiu
    Created: Thu, 26 Jun 2003 8:35 AM
       Body:
the mapping I used is:

<composite-id>
    <key-property column="COD" length="22" name="cod" type="java.lang.Long"/>
    <key-property column="DATA_FIN" length="7" name="dataFin" type="java.util.Date"/>
</composite-id>
<property column="PKID"  name="pkid" not-null="true" type="java.lang.Long"/>
<property column="NAME" length="200" name="name" not-null="true" type="java.lang.String"/>
<property column="DATA_INI" length="7" name="dataIni" not-null="true" type="java.util.Date"/>
<property column="MGR_ID" length="22" name="mgrId" type="java.lang.Long"/>
<property column="DEPT_ID" length="22" name="deptId" type="java.lang.Long"/>
<property column="BOGUS_DT_FIN" length="7" name="dataIni" not-null="true" type="java.util.Date"/>

  <many-to-one name="CurrentManager" class="CdtDACPerson" outer-join="true" insert="false">
      <column name="MGR_ID"  />
      <column name="BOGUS_DT_FIN"/>
  </many-to-one>

If the last many-to-one mapping would disappear the insert would succeed
---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-145


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-145
    Summary: insert for classes with composite-id crashes
       Type: Bug

     Status: Unassigned
   Priority: Minor

    Project: Hibernate2

   Assignee: 
   Reporter: Hrituc Ovidiu

    Created: Thu, 19 Jun 2003 10:21 AM
    Updated: Thu, 19 Jun 2003 7:09 PM
Environment: W2k professional, SQL Server 2k, OC4J

Description:
Insert for classes with composite-id crashes when persisting to SQL Server 2000.
The composite id consists of the COD, DATA_FIN combination. I am trying to keep the history of a person in the same table and the current record to be the combination (COD_Value, 01/01/3000)
The current manager's data gets pulled out with a many-to-one relationship with a composite fk (MGR_ID, BOGUS_DT_FIN).
Loading goes ok. 
Insert doesn't, the exceptions look like this:

Hibernate: insert into PERSON (PKID, NAME, DATA_INI, DEPT_ID, MGR_ID, BOGUS_DT_FIN, COD, DATA_FIN) values (?, ?, ?, ?, ?, ?, ?, ?)

Jun 19, 2003 6:02:16 PM net.sf.hibernate.util.JDBCExceptionReporter logExceptions

WARNING: SQL Error: 0, SQLState: 07009

Jun 19, 2003 6:02:16 PM net.sf.hibernate.util.JDBCExceptionReporter logExceptions

SEVERE: [Microsoft][SQLServer 2000 Driver for JDBC]Invalid parameter binding(s).

Jun 19, 2003 6:02:17 PM net.sf.hibernate.JDBCException <init>

SEVERE: Could not synchronize database state with session

java.sql.SQLException: [Microsoft][SQLServer 2000 Driver for JDBC]Invalid parameter binding(s).

	at com.microsoft.jdbc.base.BaseExceptions.createException(Unknown Source)

	at com.microsoft.jdbc.base.BaseExceptions.getException(Unknown Source)

	at com.microsoft.jdbc.base.BasePreparedStatement.validateParameterIndex(Unknown Source)

	at com.microsoft.jdbc.base.BasePreparedStatement.setObjectInternal(Unknown Source)

	at com.microsoft.jdbc.base.BasePreparedStatement.setTimestamp(Unknown Source)

	at com.evermind.sql.FilterPreparedStatement.setTimestamp(FilterPreparedStatement.java:394)

	at com.evermind.sql.FilterPreparedStatement.setTimestamp(FilterPreparedStatement.java:394)

	at net.sf.hibernate.type.TimestampType.set(TimestampType.java:27)

	at net.sf.hibernate.type.NullableType.nullSafeSet(NullableType.java:46)

	at net.sf.hibernate.type.NullableType.nullSafeSet(NullableType.java:31)

	at net.sf.hibernate.type.ComponentType.nullSafeSet(ComponentType.java:163)

	at net.sf.hibernate.persister.EntityPersister.dehydrate(EntityPersister.java:369)

	at net.sf.hibernate.persister.EntityPersister.insert(EntityPersister.java:446)

	at net.sf.hibernate.impl.ScheduledInsertion.execute(ScheduledInsertion.java:20)

	at net.sf.hibernate.impl.SessionImpl.executeAll(SessionImpl.java:2064)

	at net.sf.hibernate.impl.SessionImpl.execute(SessionImpl.java:2036)

	at net.sf.hibernate.impl.SessionImpl.flush(SessionImpl.java:1980)

	at it.saga.library.commonDataTypes.impl.CdtBLGBaseSessionBean.save(CdtBLGBaseSessionBean.java:247)

	at CdtBLGPerson_StatelessSessionBeanWrapper10.save(CdtBLGPerson_StatelessSessionBeanWrapper10.java:133)

	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

	at java.lang.reflect.Method.invoke(Method.java:324)

	at com.evermind.server.rmi.RMICallHandler.run(RMICallHandler.java:119)

	at com.evermind.server.rmi.RMICallHandler.run(RMICallHandler.java:48)

	at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:797)

	at java.lang.Thread.run(Thread.java:536)




---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HB-145) insert for classes with composite-id crashes

[<leg...@at...>]

The following comment has been added to this issue:

     Author: Hrituc Ovidiu
    Created: Thu, 26 Jun 2003 8:33 AM
       Body:
It's not the driver's fault.
With Oracle I get the same error.
If I remove the class relationship mapped using a composite-id from class's description the insert succeeds.
---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-145


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-145
    Summary: insert for classes with composite-id crashes
       Type: Bug

     Status: Unassigned
   Priority: Minor

    Project: Hibernate2

   Assignee: 
   Reporter: Hrituc Ovidiu

    Created: Thu, 19 Jun 2003 10:21 AM
    Updated: Thu, 19 Jun 2003 7:09 PM
Environment: W2k professional, SQL Server 2k, OC4J

Description:
Insert for classes with composite-id crashes when persisting to SQL Server 2000.
The composite id consists of the COD, DATA_FIN combination. I am trying to keep the history of a person in the same table and the current record to be the combination (COD_Value, 01/01/3000)
The current manager's data gets pulled out with a many-to-one relationship with a composite fk (MGR_ID, BOGUS_DT_FIN).
Loading goes ok. 
Insert doesn't, the exceptions look like this:

Hibernate: insert into PERSON (PKID, NAME, DATA_INI, DEPT_ID, MGR_ID, BOGUS_DT_FIN, COD, DATA_FIN) values (?, ?, ?, ?, ?, ?, ?, ?)

Jun 19, 2003 6:02:16 PM net.sf.hibernate.util.JDBCExceptionReporter logExceptions

WARNING: SQL Error: 0, SQLState: 07009

Jun 19, 2003 6:02:16 PM net.sf.hibernate.util.JDBCExceptionReporter logExceptions

SEVERE: [Microsoft][SQLServer 2000 Driver for JDBC]Invalid parameter binding(s).

Jun 19, 2003 6:02:17 PM net.sf.hibernate.JDBCException <init>

SEVERE: Could not synchronize database state with session

java.sql.SQLException: [Microsoft][SQLServer 2000 Driver for JDBC]Invalid parameter binding(s).

	at com.microsoft.jdbc.base.BaseExceptions.createException(Unknown Source)

	at com.microsoft.jdbc.base.BaseExceptions.getException(Unknown Source)

	at com.microsoft.jdbc.base.BasePreparedStatement.validateParameterIndex(Unknown Source)

	at com.microsoft.jdbc.base.BasePreparedStatement.setObjectInternal(Unknown Source)

	at com.microsoft.jdbc.base.BasePreparedStatement.setTimestamp(Unknown Source)

	at com.evermind.sql.FilterPreparedStatement.setTimestamp(FilterPreparedStatement.java:394)

	at com.evermind.sql.FilterPreparedStatement.setTimestamp(FilterPreparedStatement.java:394)

	at net.sf.hibernate.type.TimestampType.set(TimestampType.java:27)

	at net.sf.hibernate.type.NullableType.nullSafeSet(NullableType.java:46)

	at net.sf.hibernate.type.NullableType.nullSafeSet(NullableType.java:31)

	at net.sf.hibernate.type.ComponentType.nullSafeSet(ComponentType.java:163)

	at net.sf.hibernate.persister.EntityPersister.dehydrate(EntityPersister.java:369)

	at net.sf.hibernate.persister.EntityPersister.insert(EntityPersister.java:446)

	at net.sf.hibernate.impl.ScheduledInsertion.execute(ScheduledInsertion.java:20)

	at net.sf.hibernate.impl.SessionImpl.executeAll(SessionImpl.java:2064)

	at net.sf.hibernate.impl.SessionImpl.execute(SessionImpl.java:2036)

	at net.sf.hibernate.impl.SessionImpl.flush(SessionImpl.java:1980)

	at it.saga.library.commonDataTypes.impl.CdtBLGBaseSessionBean.save(CdtBLGBaseSessionBean.java:247)

	at CdtBLGPerson_StatelessSessionBeanWrapper10.save(CdtBLGPerson_StatelessSessionBeanWrapper10.java:133)

	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

	at java.lang.reflect.Method.invoke(Method.java:324)

	at com.evermind.server.rmi.RMICallHandler.run(RMICallHandler.java:119)

	at com.evermind.server.rmi.RMICallHandler.run(RMICallHandler.java:48)

	at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:797)

	at java.lang.Thread.run(Thread.java:536)




---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HB-160) Batch Reading

[<leg...@at...>]

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-160


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-160
    Summary: Batch Reading
       Type: New Feature

     Status: Unassigned
   Priority: Minor

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0.1

   Assignee: 
   Reporter: Mike Gorman

    Created: Thu, 26 Jun 2003 8:19 AM
    Updated: Thu, 26 Jun 2003 8:19 AM

Description:
Feature is used to reduce # queries sent to the database to retrieve related lazily initialized 1-1's.  Example:  Retrieve 20 Contact objects, each has a 1-1 to an Account.  Initial Query just asked to retrieve the Contact objects with nothing else being built initially.  If each Contact works for a different Account, then if I call getAccount on each Contact (with initially empty cache), what started as 1 query turns into 21 queries (one PK query for each Account).

Feature supports the ability for those lazy Account references to "remember" what their "originating query" was - the one used to retrieve the 20 Contact objects in the first place.  Then, when the first Contact's "account" reference is initialized, it joins with the originating query's criteria to get all of the related accounts that match the originating query's criteria, populating the cache with 20 Account objects with one query.  Now, what would otherwise be 21 queries is now just 2 (1 for the 20 Contacts, and 1 for the 20 Accounts).

Example:

originating query:  select * from contact where last_name = 'Smith'

Then, when the first uninitialized Contact.account reference is initialized (from that set of Contacts), the account query is:

select t0.* from account t0, contact t1 where t1.account_id = t0.account_id and t1.last_name = 'Smith'



---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HB-159) Trans-database Support

[<leg...@at...>]

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-159


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-159
    Summary: Trans-database Support
       Type: New Feature

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0.1

   Assignee: 
   Reporter: Mike Gorman

    Created: Thu, 26 Jun 2003 8:13 AM
    Updated: Thu, 26 Jun 2003 8:13 AM

Description:
Ability to define an object model, and specify that some classes live in database A, and some live in database B.  Hibernate should assume that it can not join between the databases and, in fact, the databases may be from different vendors.

I know this can be done by creating multiple Sessions, but I don't think this will make trans-database relationships work.  That is, I need to be able to have 1-1 and 1-M relationships defined between objects that live in two different databases.  When Hibernate goes to lazily initialize a 1-1 or 1-M relationship, it needs to be able to do so using a Connection connected to the appropriate database.  If M-M can be achieved, as well, so much the better (will require specification of which database the M-M table lives in, I believe.)

Goal is that a single Session can be used to obtain objects and resulting objects' relationships all work, even though they may be using Connections from the other database.


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HB-158) Customizable SQL

[<leg...@at...>]

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-158


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-158
    Summary: Customizable SQL
       Type: New Feature

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0.1

   Assignee: 
   Reporter: Mike Gorman

    Created: Thu, 26 Jun 2003 8:08 AM
    Updated: Thu, 26 Jun 2003 8:08 AM

Description:
Ability to be able to get the SQL Hibernate would send to the database for a given query, be able to look at it and possibly tweak it (as a String) and then allow Hibernate to continue - sending the SQL on its way to the database.  This allows for subtle hints and other database tricks one is often forced to do when you don't "own" the datamodel.


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HB-157) MapGenerator generator xml fix

[<leg...@at...>]

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-157


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-157
    Summary: MapGenerator generator xml fix
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
   Versions:
             2.0.1

   Assignee: 
   Reporter: Frank Buss

    Created: Thu, 26 Jun 2003 8:07 AM
    Updated: Thu, 26 Jun 2003 8:07 AM

Description:
HB-94 is still open with the hibernate-extensions-2.0.zip from 2003-06-12 07:00. I didn't found a way to re-open HB-94, so I submit this new bug.



---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HB-156) Qualified one-to-many

[<leg...@at...>]

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-156


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-156
    Summary: Qualified one-to-many
       Type: New Feature

     Status: Unassigned
   Priority: Blocker

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0.1

   Assignee: 
   Reporter: Mike Gorman

    Created: Thu, 26 Jun 2003 8:05 AM
    Updated: Thu, 26 Jun 2003 8:05 AM

Description:
Ability to add static criteria to what would otherwise be a one-to-many relationship, to make it into a one-to-one relationship.  Example:  Account has one-to-many relationship to Address by way of address.account_id foreign key.  However, there is only one "primary" address for a given account, indicated in the datamodel by address.is_primary = 'Y' for exactly one row for any given Account.  Enhancement would let me create a property "primaryAddress" on Account that is mapped like a one-to-many except that it also includes something like "...AND primary = true".

This allows me to obtain an Account object and call getPrimaryAddress and have that SQL query the address table "WHERE account_id = ? AND is_primary = 'Y'".


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HB-155) Optimistic locking by columns' original values

[<leg...@at...>]

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-155


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-155
    Summary: Optimistic locking by columns' original values
       Type: New Feature

     Status: Unassigned
   Priority: Blocker

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0.1

   Assignee: 
   Reporter: Mike Gorman

    Created: Thu, 26 Jun 2003 8:01 AM
    Updated: Thu, 26 Jun 2003 8:01 AM

Description:
Ability to support optimistic locking by columns' original values.  When UPDATE statements are generated, in addition to the primary key, the WHERE clause includes either all of the columns' original values, or just the changed columns' original values.  This allows optimistic locking without requiring the datamodel to have a "timestamp" or "version" column.


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HB-154) Multi-table Mappings

[<leg...@at...>]

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-154


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-154
    Summary: Multi-table Mappings
       Type: New Feature

     Status: Unassigned
   Priority: Blocker

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0.1

   Assignee: 
   Reporter: Mike Gorman

    Created: Thu, 26 Jun 2003 7:58 AM
    Updated: Thu, 26 Jun 2003 7:58 AM

Description:
Ability to map one class across two or more tables.  Assumption is that the tables can all be joined with regular joins all the time, and that the key structure matches, although the name of the columns may differ across the tables.  An insert of an object results in an insert to each of the mapped tables all using the same key value.  The
class can then map its properties to any column in any table.  This should all be done without the workaround of using a delegate or creation of a database view.


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HB-153) MapGenerator documentation bug

[<leg...@at...>]

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-153


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-153
    Summary: MapGenerator documentation bug
       Type: Bug

     Status: Unassigned
   Priority: Trivial

    Project: Hibernate2
   Versions:
             2.0.1

   Assignee: 
   Reporter: Frank Buss

    Created: Thu, 26 Jun 2003 7:39 AM
    Updated: Thu, 26 Jun 2003 7:39 AM

Description:
In chapter "16.3.1. Running the tool" the name of the class is written as "src.net.sf.hibernate.tool.class2hbm.MapGenerator", but it has to be "net.sf.hibernate.tool.class2hbm.MapGenerator".



---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HB-152) discriminator force true doesn't work

[<leg...@at...>]

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-152


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-152
    Summary: discriminator force true doesn't work
       Type: Bug

     Status: Unassigned
   Priority: Minor

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0.1

   Assignee: 
   Reporter: Jeff Boring

    Created: Thu, 26 Jun 2003 7:15 AM
    Updated: Thu, 26 Jun 2003 7:15 AM
Environment: win2000, WSAD v5, DB2, websphere v5

Description:
A discriminator force true does not cause Hibernate to ignore unmapped discriminator values, instead WrongClassException is thrown.

see http://sourceforge.net/forum/forum.php?thread_id=889426&forum_id=128638 for more info


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] Multi-table Mappings

[Gorman, M. <Mik...@jd...>]

Feature Request:  Ability to map one class across two or more tables.  =
Assumption is that the tables can all be joined with regular joins all =
the time, and that the key structure matches, although the name of the =
columns may differ across the tables.  An insert of an object results in =
an insert to each of the mapped tables all using the same key value.  =
The class can then map its properties to any column in any table.  This =
should all be done without the workaround of using a delegate.  Thank =
you.

Mike Gorman

[Hibernate-issues] [Hibernate-JIRA] Created: (HB-151) Traversing several joined-subclasses in where clause leaves out inner joins for superclasses

[<leg...@at...>]

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-151


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-151
    Summary: Traversing several joined-subclasses in where clause leaves out inner joins for superclasses
       Type: Bug

     Status: Unassigned
   Priority: Critical

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0.1

   Assignee: 
   Reporter: Sander Verbruggen

    Created: Thu, 26 Jun 2003 3:05 AM
    Updated: Thu, 26 Jun 2003 3:05 AM
Environment: WSAD 5.0.1, JDK 1.3.1, Oracle 9i, Windows 2000

Description:
Class-diagram:
a-->b  a inherits from b
a==b   a has relationship to b

(Sorry, classnames are in Dutch)

Persoon == Beroepsuitoefening
Beroepsuitoefening <-- Jurist
Jurist == Bevoegdheid
Bevoegdheid <-- Beediging <-- Procureurschap

If my query contains 'where jurist.persoon.naam like ?', the generated SQL looks like this (which is OK):

select count(*) as x0_0_ 
from jurist persiste0_ 
	inner join beroepsuitoefening persiste0__1 on persiste0_.beg_id=persiste0__1.id, 
persoon persiste1_ 
where (
	(
		persiste1_.naam like ?  
		and persiste0__1.psn_id=persiste1_.id
	)
)


However, if I start one level deeper in the hierarchy ('where procureurschap.jurist.persoon.naam like ?') the SQL query looks like this:

select count(*) as x0_0_ 
from procureurschap persiste0_ 
	inner join beediging persiste0__1 on persiste0_.bvh_id=persiste0__1.bvh_id 
	inner join bevoegdheid persiste0__2 on persiste0_.bvh_id=persiste0__2.id, 
jurist persiste1_, 
persoon persiste2_ 

where (
	(
		persiste2_.naam=?  
		and persiste0__2.beg_id=persiste1_.beg_id 
		and persiste1__1.psn_id=persiste2_.id
	)
)

[Queries are indented to show outline]

As you can see, the last clause references persiste1__1, which isn't listed in the from clause. It's intended to, because the pattern matches with the previous example (_1 begin the first innerjoin for persiste1_). It should be an alias for beroepsuitoefening just as it is in the previous example.


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HB-150) Add getSession method to Transaction interface

[<leg...@at...>]

The following comment has been added to this issue:

     Author: Chris Webb
    Created: Wed, 25 Jun 2003 11:46 PM
       Body:
See discussion: http://sourceforge.net/forum/forum.php?thread_id=888024&forum_id=128638
---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-150


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-150
    Summary: Add getSession method to Transaction interface
       Type: New Feature

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0rc2
             2.1
             2.0 final
             2.0.1
             2.0.2

   Assignee: 
   Reporter: Chris Webb

    Created: Wed, 25 Jun 2003 11:45 PM
    Updated: Wed, 25 Jun 2003 11:45 PM

Description:
It should be possible to retrieve the Session associated with a Transaction from a Transaction instance. This would assist some data access implentations by exposing the relationship in a convenient and logical manner.


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HB-150) Add getSession method to Transaction interface

[<leg...@at...>]

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-150


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-150
    Summary: Add getSession method to Transaction interface
       Type: New Feature

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0rc2
             2.1
             2.0 final
             2.0.1
             2.0.2

   Assignee: 
   Reporter: Chris Webb

    Created: Wed, 25 Jun 2003 11:45 PM
    Updated: Wed, 25 Jun 2003 11:45 PM

Description:
It should be possible to retrieve the Session associated with a Transaction from a Transaction instance. This would assist some data access implentations by exposing the relationship in a convenient and logical manner.


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HB-149) Using Sets Before Fully Initialized causes NullPointerException

[<leg...@at...>]

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-149


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-149
    Summary: Using Sets Before Fully Initialized causes NullPointerException
       Type: Bug

     Status: Unassigned
   Priority: Minor

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0.1

   Assignee: 
   Reporter: Bill Dudney

    Created: Wed, 25 Jun 2003 4:21 PM
    Updated: Wed, 25 Jun 2003 4:21 PM
Environment: JDK 1.4.1

Description:
one-to-man from A -> B

A.addB(B foo) {
  if(null != foo) {
    set_of_bs.add(foo);
    foo.setA(this);
  }
}


B.setA(A bar) {
  a = bar;
  if(null != a && !a.getBs().contains(this)) {
    a.addB(b);
  }
}

I'm not sure why but the tempList in the net.sf.hibernate.collection.Set ends up being null at some point during initialization. endRead is being called twice, the first time its ok the second time it throws a NullPointerException.

I'm not sure this is a bug with Hibernate or if I should not be maintaining the backwards pointers in this way. 


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HB-148) Old JCS jar is faster than new one (?)

[<leg...@at...>]

The following comment has been added to this issue:

     Author: John Kristian
    Created: Wed, 25 Jun 2003 12:36 PM
       Body:
See http://sourceforge.net/forum/forum.php?thread_id=883135&forum_id=128638

When I used Hibernate 1.2.5 to load a few thousand objects into a cold cache by calling Session.find("FROM entity IN CLASS X"), it took a few seconds to execute.  But it took about 7 minutes after I switched to Hibernate 2.0.  It takes about 2 seconds to execute the same test (loading the same entities) if there are no <jcs-cache> elements in the Hibernate mapping files.  Hibernate 2.0 performs much better using the version of lib/jcs.jar that was released with Hibernate 1.2.5, instead of the lib/jcs.jar that was released with Hibernate 2.0.  This combination of software can load entries into a cold cache approximately as fast as Hibernate 1.2.5.

I'm willing to test a better version of JCS, but I have been unable to build it.

- John Kristian <jkr...@do...>

P.S. I also filed JIRA report HB-156, but it seems JIRA has lost my report and also my identity (I just enrolled myself again, with the same username).

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-148


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-148
    Summary: Old JCS jar is faster than new one (?)
       Type: Task

     Status: Assigned
   Priority: Major

    Project: Hibernate2
   Versions:
             2.0.1

   Assignee: Gavin King
   Reporter: Gavin King

    Created: Fri, 20 Jun 2003 10:30 PM
    Updated: Fri, 20 Jun 2003 10:30 PM

Description:
A user reported that the build of JCS that ships with Hibernate2 is MUCH slower than the earlier build that we were using.

We need to verify this and find out why....


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HB-148) Old JCS jar is faster than new one (?)

[<leg...@at...>]

The following comment has been added to this issue:

     Author: John Kristian
    Created: Wed, 25 Jun 2003 12:36 PM
       Body:
See http://sourceforge.net/forum/forum.php?thread_id=883135&forum_id=128638

When I used Hibernate 1.2.5 to load a few thousand objects into a cold cache by calling Session.find("FROM entity IN CLASS X"), it took a few seconds to execute.  But it took about 7 minutes after I switched to Hibernate 2.0.  It takes about 2 seconds to execute the same test (loading the same entities) if there are no <jcs-cache> elements in the Hibernate mapping files.  Hibernate 2.0 performs much better using the version of lib/jcs.jar that was released with Hibernate 1.2.5, instead of the lib/jcs.jar that was released with Hibernate 2.0.  This combination of software can load entries into a cold cache approximately as fast as Hibernate 1.2.5.

I'm willing to test a better version of JCS, but I have been unable to build it.

- John Kristian <jkr...@do...>

P.S. I also filed JIRA report HB-156, but it seems JIRA has lost my report and also my identity (I just enrolled myself again, with the same username).

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-148


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-148
    Summary: Old JCS jar is faster than new one (?)
       Type: Task

     Status: Assigned
   Priority: Major

    Project: Hibernate2
   Versions:
             2.0.1

   Assignee: Gavin King
   Reporter: Gavin King

    Created: Fri, 20 Jun 2003 10:30 PM
    Updated: Fri, 20 Jun 2003 10:30 PM

Description:
A user reported that the build of JCS that ships with Hibernate2 is MUCH slower than the earlier build that we were using.

We need to verify this and find out why....


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HB-156) Slow Cache Loading

[<leg...@at...>]

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-156


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-156
    Summary: Slow Cache Loading
       Type: Bug

     Status: Unassigned
   Priority: Minor

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0 final

   Assignee: 
   Reporter: John Kristian

    Created: Tue, 24 Jun 2003 12:12 PM
    Updated: Tue, 24 Jun 2003 12:12 PM
Environment: Windows, MS SQL Server

Description:
It takes a long time to load a few thousand objects into a cold cache.  (That is a read-write JCS cache.)  One example test took 7 minutes, as opposed to one or two seconds with Hibernate 1.2.5.

Hibernate 2.0 performs much better using the version of lib/jcs.jar that was released with Hibernate 1.2.5, instead of the lib/jcs.jar that was released with Hibernate 2.0. This combination of software can load entries into a cold cache approximately as fast as Hibernate 1.2.5.  I suggest releasing future versions of Hibernate with this older version of JCS, since it seems to perform better.

I posted this issue to the SourceForge forum 'Open Discussion' for Hibernate <http://sourceforge.net/forum/message.php?msg_id=2058214>.


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HB-155) Querying collection within a component

[<leg...@at...>]

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-155


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-155
    Summary: Querying collection within a component  
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0.1

   Assignee: 
   Reporter: Rex Madden

    Created: Tue, 24 Jun 2003 11:28 AM
    Updated: Tue, 24 Jun 2003 11:28 AM

Description:
I'm switching to 2.0.1 from 1.2.3. I received the following error trying to do a query on a collection that's within a component. Obviously, this used to work in 1.2.3. I've included part of my mapping below. Using elements(mov.cast.cast.list) did not help.

net.sf.hibernate.QueryException: could not resolve property type: cast.cast.null [SELECT mov.id FROM mov in class Movie WHERE :findTarget in mov.component.list.elements] 
at net.sf.hibernate.hql.PathExpressionParser.getPropertyType(PathExpressionParser.java:223) 
at net.sf.hibernate.hql.PathExpressionParser.end(PathExpressionParser.java:270) 
at net.sf.hibernate.hql.WhereParser.preprocess(WhereParser.java:347) 
at net.sf.hibernate.hql.WhereParser.doPathExpression(WhereParser.java:355) 
at net.sf.hibernate.hql.WhereParser.doToken(WhereParser.java:389) 
at net.sf.hibernate.hql.WhereParser.token(WhereParser.java:275) 
at net.sf.hibernate.hql.ClauseParser.token(ClauseParser.java:73) 
at net.sf.hibernate.hql.PreprocessingParser.token(PreprocessingParser.java:120) 
at net.sf.hibernate.hql.ParserHelper.parse(ParserHelper.java:29) 
at net.sf.hibernate.hql.QueryTranslator.compile(QueryTranslator.java:145) 
at net.sf.hibernate.hql.QueryTranslator.compile(QueryTranslator.java:132) 
at net.sf.hibernate.impl.SessionFactoryImpl.getQuery(SessionFactoryImpl.java:373) 
at net.sf.hibernate.impl.SessionFactoryImpl.getQuery(SessionFactoryImpl.java:351) 
at net.sf.hibernate.impl.SessionImpl.getQueries(SessionImpl.java:1381) 
at net.sf.hibernate.impl.SessionImpl.find(SessionImpl.java:1345) 
at net.sf.hibernate.impl.QueryImpl.list(QueryImpl.java:76) 
at com.fetchaflick.videotest.ojb.FetchaQuery.list(FetchaQuery.java:45) 
at com.fetchaflick.videotest.movie.BaseMovieFinder.findPageBy(BaseMovieFinder.java:62) 
at com.fetchaflick.videotest.movie.BaseMovieFinder.findPageByActor(BaseMovieFinder.java:45) 
at com.fetchaflick.videotest.movie.MovieFinderTest.testFindByActor(MovieFinderTest.java:100) 
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) 
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) 

<class name="Movie" table="PRODUCT"> 
<component name="component" class="com.fetchaflick.videotest.movie.Cast"> 

<list name="list" table="MOVIE_CAST" cascade="all"> 
<jcs-cache usage="read-write"/> 
<key column="MOVIE_ID"/> 
<index column="POS"/> 
<element type="string" column="NAME"/> 
</list> 
</component> 
</class> 


Original thread on the forum
http://sourceforge.net/forum/forum.php?thread_id=889001&forum_id=128638



---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira