hibernate-issues — Hibernate JIRA Notifications

[Hibernate-issues] [Hibernate-JIRA] Commented: (HB-7) Oracle "Paging Select" w/association problem

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

The following comment has been added to this issue:

     Author: Dave White
    Created: Fri, 11 Jul 2003 2:27 PM
       Body:
Gavin,

Sorry, but I was unable to verify that this was fixed for quite some
time.  I just recently got around to checking this and found that
this wasn't actually fixed.  I looked into this a bit deeper and found that the problem seems to stem from the fact that when generating the the SQL select statement for an entity, the "identity" and the "rest of the properties" are generated in two seperate code paths.  Here's a snippet from QueryTranslator which shows where the problem lies:

if ( !shallowQuery ) {
    renderIdentifierSelect(sql);
    renderPropertiesSelect(sql);
}

I saw that there was a fix put into SelectFragment in the sql package, which filters out duplicate columns when generating the columns to select.  The problem is that this only worked when there were duplicates in only in the identity or only in the "other" properties.  When the same colum is defined in the identity portion and in a composite many-to-one association, it is still broken.

I have applied a fix to this in my local source tree that involves the files:

.\src\net\sf\hibernate\hql\QueryTranslator.java
.\src\net\sf\hibernate\loader\OuterJoinLoader.java
.\src\net\sf\hibernate\persister\AbstractEntityPersister.java
.\src\net\sf\hibernate\persister\EntityPersister.java
.\src\net\sf\hibernate\persister\Loadable.java
.\src\net\sf\hibernate\persister\NormalizedEntityPersister.java
.\src\net\sf\hibernate\sql\SelectFragment.java

What I did was basically add an append(SelectFragment fragment)
method to the SelectFragment class.  I then changed all places that were building the identity & "other" properties select fragments seperately, to build them together by appending one to the other.  By doing this, I was able to take advantage of the duplicate filtering that the SelectFragment is already doing in its toFragmentString()
method.

Let me know if you'd like me to submit these changes as a patch.

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

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-7
    Summary: Oracle "Paging Select" w/association problem   
       Type: Bug

     Status: Closed
   Priority: Major
 Resolution: FIXED

    Project: Hibernate2
 Components: 
             core
   Fix Fors:
             2.0 final
   Versions:
             2.0rc2

   Assignee: Gavin King
   Reporter: Dave White

    Created: Wed, 30 Apr 2003 9:06 PM
    Updated: Wed, 11 Jun 2003 8:03 AM

Description:
I have a mapping that looks like this: 

<class name="Foo" proxy="Foo" table="Tbl_Foo" dynamic-update="true"> 
  <composite-id name="fooKey" class="FooKey"> 
    <key-property name="barId" column="barID" type="int"/> 
    <key-property name="id2"   column="ID2"   type="int"/> 
  </composite-id> 
  <property name="location" column="Location" type="string"/> 
  <many-to-one name="barRef" class="Bar" cascade="none" 
               insert="false" update="false"> 
    <column name="barID"/> 
  </many-to-one> 
</class> 

As you can see, the the id of Foo is the same as the foreign key used in the many-to-one association to Bar. I've used the insert/update attributes to say that the barID column should not be include (twice) in the insert/update statements. However, when I do a query against this class the generated SQL contains the barID column twice in the select statement. Once for the composite-id, and once for the many-to-one association. This became a problem when I applied my "paging select" patch for Oracle which looks like this: 

select * 
from (select a.*, rownum rnum 
from ( <hibernate-generated-sql> ) a 
where rownum <= ?) 
where rnum >= ? 

The reason this is a problem is that when the <hibernate-generated-sql> statement contains the same column twice in the select clause, Oracle complains about ambiguously declared columns. I'm wondering if different aliases could be generated in the SQL for columns defined in composite-id vs. property vs. many-to-one? 

I did look into the <key-many-to-one> tag in the composite-id, but that didn't fit well with my (already-in-place/legacy) object model. 



---------------------------------------------------------------------
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-185) flush() does not cleanup after a SQLException

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-185
    Summary: flush() does not cleanup after a SQLException
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0.1

   Assignee: 
   Reporter: Dave White

    Created: Fri, 11 Jul 2003 2:07 PM
    Updated: Fri, 11 Jul 2003 2:07 PM

Description:
I have a object mapped with a composite-id.  In the database, there is a unique composite index against the columns that make up the composite-id.  I've found that when I do the following:

try {
  session.save(foo); // where foo is the object with the composite-id
  session.flush();
  // Do some other work with session
}
finally {
  session.flush();
  session.close();
}

that if a SQLException is thrown in the first session.flush (because the insert statement violated the unique constraint of the index), the second flush throws the same exception.  The means that the flush() call doesn't cleanup the "things to be done" in the case that an exception is thrown during the flushing process.  Specifically, I found the following in SessionImpl.

private void executeAll(Iterator iter) throws SQLException, HibernateException {
    while ( iter.hasNext() ) {
	Executable e = (Executable) iter.next();
	executions.add(e);	
        e.execute();
        iter.remove();        		
	if ( batcher!=null ) batcher.executeBatch();
    }
}

I'm wondering if perhaps it would be better if this was:

private void executeAll(Iterator iter) throws SQLException, HibernateException {
    while ( iter.hasNext() ) {
	Executable e = (Executable) iter.next();
	executions.add(e);
        try {	
            e.execute();
        }
        finally {
            iter.remove();        		
        }
	if ( batcher!=null ) batcher.executeBatch();
    }
}

After making this change in my local source tree, the problem I descrived above was fixed.


---------------------------------------------------------------------
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-183) Add <where> clause for main class

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

The following comment has been added to this issue:

     Author: Max Rydahl Andersen
    Created: Fri, 11 Jul 2003 10:59 AM
       Body:
No biggie ;) Just pointing out a possible solution.

Don't know if it will be implemented, but patches are welcome ;)
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-183
    Summary: Add <where> clause for main class
       Type: New Feature

     Status: Unassigned
   Priority: Minor

    Project: Hibernate2
   Versions:
             2.0.1

   Assignee: 
   Reporter: Tom Sedge

    Created: Fri, 11 Jul 2003 2:57 AM
    Updated: Fri, 11 Jul 2003 2:57 AM
Environment: N/A

Description:
Please add a simple way to add a where clause on all SELECTs for a class - like the <where> tag in collections.

The situation is that I am mapping a legacy table where I don't want or need to deal with all rows. Therefore on a SELECT * or any other query I only want to select certain rows. Which rows depends on the value of two columns (e.g. where t.c1 > 20 and t.c2 < 300) so a discriminator is no help for this. 

However, I *do* have more than one type of object in the table, which is why I wish to ignore some rows. 

I daresay I could do this with a custom persister, but it looks like this should be built-in functionality to me. 



---------------------------------------------------------------------
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-184) Connection Timeout Exception using MySQL and DBCP

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-184
    Summary: Connection Timeout Exception using MySQL and DBCP
       Type: Patch

     Status: Unassigned
   Priority: Major

    Project: Hibernate2

   Assignee: 
   Reporter: Maarten Coene

    Created: Fri, 11 Jul 2003 9:21 AM
    Updated: Fri, 11 Jul 2003 9:21 AM
Environment: Linux

Description:
Hi,

The MySQL database closes by default it connections after 8 hours. If these connections are pooled, a "Connetion Timeout" exception will be thrown if you try to access the connection. The best way to solve this is to add ?autoReconnect=true to the jdbc url.

But this doesn't work with Hibernate and DBCP.

The reason is that this option only works if the autoCommit attribute is set to true and the DBCPConnectionProvider of Hibernate sets this to false by default. I've created a patch to fix this problem.

thx
Maarten Coene



Index: DBCPConnectionProvider.java
===================================================================
RCS file: /cvsroot/hibernate/Hibernate2/src/net/sf/hibernate/connection/DBCPConnectionProvider.java,v
retrieving revision 1.8
diff -u -r1.8 DBCPConnectionProvider.java
--- DBCPConnectionProvider.java	25 Apr 2003 03:40:31 -0000	1.8
+++ DBCPConnectionProvider.java	11 Jul 2003 14:12:09 -0000
@@ -42,6 +42,7 @@
 		try {
 			final Connection c = ds.getConnection();
 			if (isolation!=null) c.setTransactionIsolation( isolation.intValue() );
+                        c.setAutoCommit(false);
 			return c;
 		}
 		catch (SQLException sqle) {
@@ -56,6 +57,7 @@
 	
 	public void closeConnection(Connection conn) throws SQLException {
 		try {
+                        conn.setAutoCommit(true);
 			conn.close();
 		}
 		catch (SQLException sqle) {
@@ -119,7 +121,7 @@
 			// the "real" Connections created by the ConnectionFactory with
 			// the classes that implement the pooling functionality.
 			String validationQuery = props.getProperty(Environment.DBCP_VALIDATION_QUERY);
-			new PoolableConnectionFactory(connectionFactory, connectionPool, statementPool, validationQuery, false, false);
+			new PoolableConnectionFactory(connectionFactory, connectionPool, statementPool, validationQuery, false, true);
 			
 			// Finally, we create the PoolingDriver itself,
 			// passing in the object pool we created.



---------------------------------------------------------------------
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-183) Add <where> clause for main class

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

The following comment has been added to this issue:

     Author: Tom Sedge
    Created: Fri, 11 Jul 2003 8:05 AM
       Body:
It is not always appropriate (or feasible) to define views to solve this issue (update needs, efficiency, etc...).  What's the big deal about implementing this - we already have it for collections?

Seems simple enough to me.
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-183
    Summary: Add <where> clause for main class
       Type: New Feature

     Status: Unassigned
   Priority: Minor

    Project: Hibernate2
   Versions:
             2.0.1

   Assignee: 
   Reporter: Tom Sedge

    Created: Fri, 11 Jul 2003 2:57 AM
    Updated: Fri, 11 Jul 2003 2:57 AM
Environment: N/A

Description:
Please add a simple way to add a where clause on all SELECTs for a class - like the <where> tag in collections.

The situation is that I am mapping a legacy table where I don't want or need to deal with all rows. Therefore on a SELECT * or any other query I only want to select certain rows. Which rows depends on the value of two columns (e.g. where t.c1 > 20 and t.c2 < 300) so a discriminator is no help for this. 

However, I *do* have more than one type of object in the table, which is why I wish to ignore some rows. 

I daresay I could do this with a custom persister, but it looks like this should be built-in functionality to me. 



---------------------------------------------------------------------
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-183) Add <where> clause for main class

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

The following comment has been added to this issue:

     Author: Max Rydahl Andersen
    Created: Fri, 11 Jul 2003 5:22 AM
       Body:
Why not just define a View for that ? 
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-183
    Summary: Add <where> clause for main class
       Type: New Feature

     Status: Unassigned
   Priority: Minor

    Project: Hibernate2
   Versions:
             2.0.1

   Assignee: 
   Reporter: Tom Sedge

    Created: Fri, 11 Jul 2003 2:57 AM
    Updated: Fri, 11 Jul 2003 2:57 AM
Environment: N/A

Description:
Please add a simple way to add a where clause on all SELECTs for a class - like the <where> tag in collections.

The situation is that I am mapping a legacy table where I don't want or need to deal with all rows. Therefore on a SELECT * or any other query I only want to select certain rows. Which rows depends on the value of two columns (e.g. where t.c1 > 20 and t.c2 < 300) so a discriminator is no help for this. 

However, I *do* have more than one type of object in the table, which is why I wish to ignore some rows. 

I daresay I could do this with a custom persister, but it looks like this should be built-in functionality to me. 



---------------------------------------------------------------------
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-183) Add <where> clause for main class

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-183
    Summary: Add <where> clause for main class
       Type: New Feature

     Status: Unassigned
   Priority: Minor

    Project: Hibernate2
   Versions:
             2.0.1

   Assignee: 
   Reporter: Tom Sedge

    Created: Fri, 11 Jul 2003 2:57 AM
    Updated: Fri, 11 Jul 2003 2:57 AM
Environment: N/A

Description:
Please add a simple way to add a where clause on all SELECTs for a class - like the <where> tag in collections.

The situation is that I am mapping a legacy table where I don't want or need to deal with all rows. Therefore on a SELECT * or any other query I only want to select certain rows. Which rows depends on the value of two columns (e.g. where t.c1 > 20 and t.c2 < 300) so a discriminator is no help for this. 

However, I *do* have more than one type of object in the table, which is why I wish to ignore some rows. 

I daresay I could do this with a custom persister, but it looks like this should be built-in functionality to me. 



---------------------------------------------------------------------
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-182) dirtyProperties array incorrect following Interceptor.onFlushDirty

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-182
    Summary: dirtyProperties array incorrect following Interceptor.onFlushDirty
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
   Versions:
             2.0.1

   Assignee: 
   Reporter: Tom Ward

    Created: Fri, 11 Jul 2003 2:54 AM
    Updated: Fri, 11 Jul 2003 2:54 AM

Description:
As Simon Spero noted in issue HB-4, in SessionImpl.flushEntities, the dirtyProperties array is calculated before Interceptor.onFlushDirty is called.  As onFlushDirty has no way of reporting which of the currentState properties it has changed, if onFlushDirty does change a property, the dirtyProperties array will be incorrect.  This seems to be an issue in the following scenario -

A superclass Super defines an id and a dateModified property, while a subclass Sub defines a commentText property.  Sub is mapped as a joined-subclass of Super.  An Interceptor is written to change the dateModified property in the currentState to the current date, whenever onFlushDirty is called.

The issue is this - if commentText is changed and the object is flushed, the Interceptor correctly modifies the dateModified.  This change makes its way back to the instance of Sub, as expected.  However, when the time comes to update the object in the database, only the commentText is updated.  I believe that this is because as a joined-subclass, Sub is mapped across two tables, but the dirtyProperties array, calculcated before the call to onFlushDirty, only shows a change affecting one of these tables.

The ways I've found to work-around this are -

1) If using Interceptors, use a mapping strategy other than joined-subclasses.

2) Implement Interceptor.findDirty to return the properties you know will change in onFlushDirty (if other properties are dirty too).  This seems very awkward.

For me, the ideal solution would be to change the return type of Interceptor.onFlushDirty to an int[], indicating the properties which have been changed.  Then it would be a simple task to calculate the union of this array and dirtyProperties (and maybe even recheck the intersection).

I hope this is all helpful - I have read and re-read the javadocs to try and make sure I'm not missing anything, but it is still possible.  I'll give as much help as I can trying to fix this.


---------------------------------------------------------------------
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-181) ClassCast with SortedSet

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-181
    Summary: ClassCast with SortedSet
       Type: Bug

     Status: Assigned
   Priority: Major

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0.1

   Assignee: Gavin King
   Reporter: Gavin King

    Created: Fri, 11 Jul 2003 12:16 AM
    Updated: Fri, 11 Jul 2003 12:16 AM
Environment: Reported by Jason Horne 

Description:
https://sourceforge.net/forum/message.php?msg_id=1875250


I'm not sure if this is related, but we are getting a ClassCastException because TreeMap is trying to cast our objects into Comparables since it can't find a Comparator. We defined a comparator, though, and it looks like it's copied most of the time. 

However, it looks like this constructor for SortedSet: 

public SortedSet(SessionImplementor session, java.util.SortedSet set) { 
super(session, set); 
} 


...should copy the comparator as well. When this constructor is called by SortedSetType.wrap(...), the comparator isn't copied to the hibernate SortedSet class from the java.util.SortedSet class. 


---------------------------------------------------------------------
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-180) SchemaExport drop broken for Postgresql

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-180
    Summary: SchemaExport drop broken for Postgresql
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
   Versions:
             2.0 final

   Assignee: 
   Reporter: Chris Nokleberg

    Created: Thu, 10 Jul 2003 10:45 PM
    Updated: Thu, 10 Jul 2003 10:45 PM

Description:
Since PostgreSQLDialect.getCascadeConstraintsString was changed to return "", it is now necessary for dropConstraints to return true.

Alternatively, Configuration.generateDropSchemaScript should sort the tables by foreign key constraints and drop in the correct order, avoiding any need to cascade.



---------------------------------------------------------------------
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-179) Query collection in 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-179


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-179
    Summary: Query collection in component
       Type: Bug

     Status: Assigned
   Priority: Major

    Project: Hibernate2
 Components: 
             core
   Fix Fors:
             2.0.2
   Versions:
             2.0.1

   Assignee: Gavin King
   Reporter: Gavin King

    Created: Thu, 10 Jul 2003 9:07 PM
    Updated: Thu, 10 Jul 2003 9:07 PM
Environment: From Rex Madden

Description:
http://sourceforge.net/forum/message.php?msg_id=2073580


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. Any advice on how to get this to work would be appreciated.

net.sf.hibernate.QueryException: could not resolve property type: cast.cast.null [SELECT mov.id FROM mov in class com.fetchaflick.videotest.movie.Movie WHERE :findTarget in mov.cast.cast.list.elements AND mov.status >= :status ORDER BY mov.nakedTitle desc]
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="com.fetchaflick.videotest.movie.Product" table="PRODUCT">
<jcs-cache usage="read-write"/>
<id name="id" column="id" type="long" unsaved-value="0">
<generator class="assigned"/>
</id>
<discriminator column="TYPE"/>


<version column="version" name="version" type="integer"/>
<property name="status" column="STATUS" type="com.fetchaflick.videotest.ojb.ProductStatusFieldConversion"/>

<many-to-one name="priceLevel" column="PRICE_LEVEL_ID" class="com.fetchaflick.videotest.movie.PriceLevel"
cascade="none" outer-join="auto"/>

<subclass name="com.fetchaflick.videotest.movie.BaseMovie" discriminator-value="basemovie">


<property name="releaseDate" column="RELEASE_DATE"/>
<property name="nakedTitle" column="NAKED_TITLE"/>

<many-to-one
name="releaseType"
column="RELEASE_TYPE_ID"
class="com.fetchaflick.videotest.movie.ReleaseType"
cascade="none"
/>



<component name="cast" class="com.fetchaflick.videotest.movie.Cast">
<component name="cast" class="com.fetchaflick.videotest.movie.SafeList">
<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>
</component>


<subclass name="com.fetchaflick.videotest.movie.AdultMovie" discriminator-value="adult">
<property name="studio" column="STUDIO"/>
</subclass>

<subclass name="com.fetchaflick.videotest.movie.Movie" discriminator-value="movie">
<component name="criticReviews" class="com.fetchaflick.videotest.movie.CriticReviewList">
<component name="reviews" class="com.fetchaflick.videotest.movie.SafeList">
<list name="list" table="MOVIE_CRITIC_REVIEWS" cascade="all">
<jcs-cache usage="read-write"/>
<key column="MOVIE_ID"/>
<index column="POS"/>
<composite-element class="com.fetchaflick.videotest.movie.CriticReview">
<property name="author" column="AUTHOR"/>
<property name="link" column="LINK"/>
<property name="publication" column="PUBLICATION"/>
<property name="rating" type="com.fetchaflick.videotest.ojb.CriticReviewRatingFieldConversion">
<column name="RATING"/>
<column name="RATING_MAX"/>
</property>
<property name="synopsis" column="SYNOPSIS"/>
</composite-element>
</list>
</component>
</component>

</subclass>



</subclass>


</class> 


---------------------------------------------------------------------
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-178) Serialization of SessionFactory fails with Tomcat context reload

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-178
    Summary: Serialization of SessionFactory fails with Tomcat context reload
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             core
   Fix Fors:
             2.0.2
   Versions:
             2.0.1

   Assignee: 
   Reporter: Christian Bauer

    Created: Thu, 10 Jul 2003 6:35 PM
    Updated: Thu, 10 Jul 2003 6:35 PM
Environment: Linux, Tomcat 4.1.24, JDK 1.4.1, tested with current CVS

Description:
When Tomcat reloads an app context, the SessionFactory and its Sessions are loaded from the HttpSession files. I thought this would be fixed with the "null" in the UUIDGenerator fix, but it still throws an Exception on context restart. Everything else works fine, so no showstopper.

StandardManager[]: Seeding random number generator class java.security.SecureRandom

StandardManager[]: Seeding of random number generator has been completed

APP -  WARN - SessionFactoryObjectFactory - Not found: ff808081f64e8ea500f64e8ea78e0000
APP -  WARN - SessionFactoryObjectFactory - Not found: null

StandardManager[] IOException while loading persisted sessions: java.io.InvalidObjectException: Could not find a SessionFactory named: null
java.io.InvalidObjectException: Could not find a SessionFactory named: null
        at net.sf.hibernate.impl.SessionFactoryImpl.readResolve(SessionFactoryImpl.java:526)
        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 java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:911)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1655)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
        at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1845)
        at java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:452)
        at net.sf.hibernate.impl.SessionImpl.readObject(SessionImpl.java:348)
        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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:824)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1746)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1646)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324)
        at org.apache.catalina.session.StandardSession.readObject(StandardSession.java:1369)
        at org.apache.catalina.session.StandardSession.readObjectData(StandardSession.java:864)
        at org.apache.catalina.session.StandardManager.load(StandardManager.java:440)
        at org.apache.catalina.session.StandardManager.start(StandardManager.java:655)
        at org.apache.catalina.core.StandardContext.reload(StandardContext.java:2572)
        at org.apache.catalina.loader.WebappLoader$WebappContextNotifier.run(WebappLoader.java:1369)
        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] Closed: (HB-154) MapGenerator documentation bug

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

Message:

   The following issue has been closed.

   Resolver: Christian Bauer
       Date: Thu, 10 Jul 2003 4:44 PM

Fixed in CVS.
---------------------------------------------------------------------
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: MapGenerator documentation bug
       Type: Bug

     Status: Closed
   Priority: Trivial
 Resolution: FIXED

    Project: Hibernate2
 Components: 
             core
   Fix Fors:
             2.0.2
   Versions:
             2.0.1

   Assignee: Christian Bauer
   Reporter: Christian Bauer

    Created: Tue, 8 Jul 2003 3:35 PM
    Updated: Thu, 10 Jul 2003 4:44 PM

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-177) (Includes Fix) Return type of aggregate function, sum, when applied over booleans should be an integer, giving the number of true 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-177


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-177
    Summary: (Includes Fix) Return type of aggregate function, sum, when applied over booleans should be an integer, giving the number of true values
       Type: New Feature

     Status: Unassigned
   Priority: Minor

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

   Assignee: 
   Reporter: Hugh Leather

    Created: Thu, 10 Jul 2003 3:38 PM
    Updated: Thu, 10 Jul 2003 3:38 PM
Environment: MySql

Description:
When doing a select which aggregates a sum of booleans, the result is also a boolean.  I think this is no so useful and would prefer the number of true values.  This is what seems to be returned from the underlying sql, but the information is destroyed by casting to a boolean.  

The fix I have for this issue is a few small chnges to SelectParser.java.  Here is the new file, with my additions marked by comments along the lines of // Begin change ...

If anyone things this is worth adding and intends to do so, could you email me aat hug...@ho... and let me know.

    Thanks,

    Hugh.

//$Id: SelectParser.java,v 1.12 2003/05/07 15:09:05 oneovthafew Exp $
package net.sf.hibernate.hql;

import java.sql.Types;
import java.util.HashSet;
import java.util.Set;

import net.sf.hibernate.AssertionFailure;
import net.sf.hibernate.Hibernate;
import net.sf.hibernate.MappingException;
import net.sf.hibernate.QueryException;
// Begin change : Hugh Leather 10.07.2003 (See comment at top of file)
import net.sf.hibernate.type.BooleanType;
// End change : Hugh Leather 10.07.2003 (See comment at top of file)
import net.sf.hibernate.type.Type;
import net.sf.hibernate.util.StringHelper;

/**
 * Parsers the select clause of a hibernate query, looking
 * for a table (well, really class) alias.
 */
// Change : Hugh Leather 10.07.2003
// Several small changes are introduced to ensure that the return type of the
// sum aggregate function over booleans gives an integer result.

public class SelectParser implements Parser {
	
	private static final Set aggregateFunctions = new HashSet();
	private static final Set countArguments = new HashSet();
	static {
		aggregateFunctions.add("count");
		aggregateFunctions.add("avg");
		aggregateFunctions.add("max");
		aggregateFunctions.add("min");
		aggregateFunctions.add("sum");
		
		countArguments.add("distinct");
		countArguments.add("all");
		countArguments.add("*");
	}
	
	private boolean ready;
	private boolean aggregate;
	private boolean count;
	private boolean avg;
        // Begin change : Hugh Leather 10.07.2003 (See comment at top of file)
        private boolean sum;
        // End change : Hugh Leather 10.07.2003 (See comment at top of file)
	private boolean first;
	private boolean afterNew;
	private Class holderClass;
	
	private SelectPathExpressionParser pathExpressionParser = new SelectPathExpressionParser();
	private PathExpressionParser aggregatePathExpressionParser = new PathExpressionParser();
	
	public void token(String token, QueryTranslator q) throws QueryException {
		
		String lctoken = token.toLowerCase();
		
		if (first) {
			first = false;
			if ( lctoken.equals("distinct") ) {
				q.setDistinct(true);
				return;
			}
			else if ( lctoken.equals("all") ) {
				q.setDistinct(false);
				return;
			}
		}
		
		if (afterNew) {
			afterNew=false;
			holderClass = q.getImportedClass(token);
			if (holderClass==null) throw new QueryException("class not found: " + token);
			q.setHolderClass(holderClass);
		}
		else if ( token.equals(StringHelper.COMMA) ) {
			if (ready) throw new QueryException("alias or expression expected in SELECT");
			q.appendScalarSelectToken(StringHelper.COMMA_SPACE);
			ready=true;
		}
		else if ( "new".equals(lctoken) ) {
			afterNew=true;
			ready=false;
		}
		else if ( StringHelper.OPEN_PAREN.equals(token) ) {
			if (!aggregate && holderClass!=null && !ready) {
				//opening paren in new Foo ( ... )
				ready=true;
			}
			else if (aggregate) {
				q.appendScalarSelectToken(token);
			}
			else {
				throw new QueryException("aggregate function expected before ( in SELECT");
			}
			ready = true;
		}
		else if ( StringHelper.CLOSE_PAREN.equals(token) ) {
			if (holderClass!=null && !ready) {
				//closing paren in new Foo ( ... )
			}
			else if (aggregate && ready) {
				q.appendScalarSelectToken(token);
			}
			else {
				throw new QueryException("( expected before ) in select");
			}
			count=false;
			aggregate = false;
			ready = false;
		}
		else if ( countArguments.contains(lctoken) ) {
			if ( !ready || !aggregate ) throw new QueryException( token + " only allowed inside aggregate function in SELECT");
			q.appendScalarSelectToken(token);
		}
		else if ( aggregateFunctions.contains(lctoken) ) {
			if (!ready) throw new QueryException(", expected before aggregate function in SELECT: " + token);
			if ( lctoken.equals("count") ) {
				q.addSelectScalar(Hibernate.INTEGER); //must be handled differently 'cos of count(*)
				count = true;
			}
			else if ( lctoken.equals("avg") ) {
				avg = true;
			}
                        // Begin change : Hugh Leather 10.07.2003 (See comment at top of file)
                        else if( lctoken.equals("sum") ) {
                            sum = true;
                        }
                        // End change : Hugh Leather 10.07.2003 (See comment at top of file)
			aggregate = true;
			ready = false;
			q.appendScalarSelectToken(token);
		}
		else if (aggregate) {
			if (!ready) throw new QueryException("( expected after aggregate function in SELECT");
			ParserHelper.parse(aggregatePathExpressionParser, q.unalias(token), ParserHelper.PATH_SEPARATORS, q);
			
			if ( aggregatePathExpressionParser.isCollectionValued() ) {
				q.addCollection(
					aggregatePathExpressionParser.getCollectionName(),
					aggregatePathExpressionParser.getCollectionRole()
				);
			}
			q.appendScalarSelectToken( aggregatePathExpressionParser.getWhereColumn() );
			if (!count) q.addSelectScalar( aggregateType( aggregatePathExpressionParser.getWhereColumnType(), q ) );
			aggregatePathExpressionParser.addAssociation(q);
		}
		else {
			if (!ready) throw new QueryException(", expected in SELECT");
			ParserHelper.parse(pathExpressionParser, q.unalias(token), ParserHelper.PATH_SEPARATORS, q);
			if ( pathExpressionParser.isCollectionValued() ) {
				q.addCollection(
					pathExpressionParser.getCollectionName(),
					pathExpressionParser.getCollectionRole()
				);
			}
			else if ( pathExpressionParser.getWhereColumnType().isEntityType() ) {
				q.addSelectClass( pathExpressionParser.getSelectName() );
			}
			q.appendScalarSelectTokens( pathExpressionParser.getWhereColumns() );
			q.addSelectScalar( pathExpressionParser.getWhereColumnType() );
			pathExpressionParser.addAssociation(q);
			
			ready = false;
		}
	}
	
	public Type aggregateType(Type type, QueryTranslator q) throws QueryException {
		if (count) {
			throw new AssertionFailure("count(*) must be handled differently");
		}
		else if (avg) {
			int[] sqlTypes;
			try {
				sqlTypes = type.sqlTypes(q.factory);
			}
			catch (MappingException me) {
				throw new QueryException(me);
			}
			if (sqlTypes.length!=1) throw new QueryException("multi-column type in avg()");
			int sqlType = sqlTypes[0];
			if ( sqlType==Types.INTEGER || sqlType==Types.BIGINT || sqlType==Types.TINYINT ) {
				return Hibernate.FLOAT;
			}
			else {
				return type;
			}
				
		}
                // Begin change : Hugh Leather 10.07.2003 (See comment at top of file)
                else if (sum) {
                    if (type instanceof BooleanType) {
                        return Hibernate.INTEGER;
                    }
                    else {
                        return type;
                    }
                }
                // End change : Hugh Leather 10.07.2003 (See comment at top of file)
		else {
			return type;
		}
	}
	
	public void start(QueryTranslator q) {
		ready=true;
		first=true;
		aggregate=false;
		count = false;
		avg = false;
		afterNew = false;
		holderClass = null;
	}
	
	public void end(QueryTranslator q) {
	}
	
}



---------------------------------------------------------------------
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] Updated: (HB-176) Allow for Dialect specific seperator between schema and table name

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

The following issue has been updated:

    Updater: Chris Hane (mailto:ch...@it...)
       Date: Thu, 10 Jul 2003 3:04 PM
    Comment:
Added method getSchemaSeperator() that return StringHelper.DOT
    Changes:
             Attachment changed to Dialect.diff
    ---------------------------------------------------------------------
For a full history of the issue, see:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-176&page=history

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

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-176
    Summary: Allow for Dialect specific seperator between schema and table name
       Type: Patch

     Status: Unassigned
   Priority: Trivial

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0.2

   Assignee: 
   Reporter: Chris Hane

    Created: Thu, 10 Jul 2003 3:02 PM
    Updated: Thu, 10 Jul 2003 3:04 PM

Description:
I'm on the receiving end of a Hibernate mapping file(s) that use the schema attributes.  However, I am using MySQL which does not support schema (at least with the dot notation).

I added to Dialect:
getSchemaSeperator which will supply the default seperator found in Table (StringHelper.DOT).

In MySQLDialect I overrode this function to provide StringHelper.UNDERSCORE

I modified Table to use the new attribute from Dialect in getQualifiedName()

The source I modified was the latest (2003-07-10) pulled from CVS.

Chris....


---------------------------------------------------------------------
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] Updated: (HB-176) Allow for Dialect specific seperator between schema and table name

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

The following issue has been updated:

    Updater: Chris Hane (mailto:ch...@it...)
       Date: Thu, 10 Jul 2003 3:05 PM
    Comment:
Overrode getSchemaSeperator() to return StringHeler.UNDERSCORE so that schemas can be used with MySQL
    Changes:
             Attachment changed to MySQLDialect.diff
    ---------------------------------------------------------------------
For a full history of the issue, see:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-176&page=history

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

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-176
    Summary: Allow for Dialect specific seperator between schema and table name
       Type: Patch

     Status: Unassigned
   Priority: Trivial

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0.2

   Assignee: 
   Reporter: Chris Hane

    Created: Thu, 10 Jul 2003 3:02 PM
    Updated: Thu, 10 Jul 2003 3:05 PM

Description:
I'm on the receiving end of a Hibernate mapping file(s) that use the schema attributes.  However, I am using MySQL which does not support schema (at least with the dot notation).

I added to Dialect:
getSchemaSeperator which will supply the default seperator found in Table (StringHelper.DOT).

In MySQLDialect I overrode this function to provide StringHelper.UNDERSCORE

I modified Table to use the new attribute from Dialect in getQualifiedName()

The source I modified was the latest (2003-07-10) pulled from CVS.

Chris....


---------------------------------------------------------------------
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] Updated: (HB-176) Allow for Dialect specific seperator between schema and table name

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

The following issue has been updated:

    Updater: Chris Hane (mailto:ch...@it...)
       Date: Thu, 10 Jul 2003 3:04 PM
    Comment:
Modified both getQualifiedName() methods to use Dialect.getSchemaSeperator instead of defaulting to StringHelper.DOT
    Changes:
             Attachment changed to Table.diff
    ---------------------------------------------------------------------
For a full history of the issue, see:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-176&page=history

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

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-176
    Summary: Allow for Dialect specific seperator between schema and table name
       Type: Patch

     Status: Unassigned
   Priority: Trivial

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0.2

   Assignee: 
   Reporter: Chris Hane

    Created: Thu, 10 Jul 2003 3:02 PM
    Updated: Thu, 10 Jul 2003 3:04 PM

Description:
I'm on the receiving end of a Hibernate mapping file(s) that use the schema attributes.  However, I am using MySQL which does not support schema (at least with the dot notation).

I added to Dialect:
getSchemaSeperator which will supply the default seperator found in Table (StringHelper.DOT).

In MySQLDialect I overrode this function to provide StringHelper.UNDERSCORE

I modified Table to use the new attribute from Dialect in getQualifiedName()

The source I modified was the latest (2003-07-10) pulled from CVS.

Chris....


---------------------------------------------------------------------
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-176) Allow for Dialect specific seperator between schema and table name

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-176
    Summary: Allow for Dialect specific seperator between schema and table name
       Type: Patch

     Status: Unassigned
   Priority: Trivial

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0.2

   Assignee: 
   Reporter: Chris Hane

    Created: Thu, 10 Jul 2003 3:02 PM
    Updated: Thu, 10 Jul 2003 3:02 PM

Description:
I'm on the receiving end of a Hibernate mapping file(s) that use the schema attributes.  However, I am using MySQL which does not support schema (at least with the dot notation).

I added to Dialect:
getSchemaSeperator which will supply the default seperator found in Table (StringHelper.DOT).

In MySQLDialect I overrode this function to provide StringHelper.UNDERSCORE

I modified Table to use the new attribute from Dialect in getQualifiedName()

The source I modified was the latest (2003-07-10) pulled from CVS.

Chris....


---------------------------------------------------------------------
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-175) One-to-many association does not correctly discriminate when a subclass is specified

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-175
    Summary: One-to-many association does not correctly discriminate when a subclass is specified
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0.1

   Assignee: 
   Reporter: Peachawat Peachavanish

    Created: Thu, 10 Jul 2003 1:49 PM
    Updated: Thu, 10 Jul 2003 1:49 PM
Environment: Gentoo Linux, Sun Java 1.4.1

Description:
When using one-to-many association from 'Parent' to 'SubChild_1' and 'SubChild_2' where 'SubChild_1' and 'SubChild_2' are subclasses of 'Child', the generated SQL for hydrating a 'Parent' does not appropriate include 'where' clause to discriminate 'SubChild_1' or 'SubChild_2'.

Class Declaration
=================
'Child.java'
public abstract class Child{}

'SubChild_1.java'
public class SubChild_1 extends Child {}

'SubChild_2.java'
public class SubChild_2 extends Child {}

'Parent.java'
public class Parent {
  private List subChilds_1 = new ArrayList();
  private List subChilds_2 = new ArrayList();
}

Mapping
=======
'Child.hbm.xml'
<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
  "-//Hibernate/Hibernate Mapping DTD 2.0//EN"
  "http://hibernate.sourceforge.net/hibernate-mapping-2.0.dtd">

<hibernate-mapping>
  <class name="Child" discriminator-value="_">
    <id name="id">
      <generator class="native"/>
    </id>
    <discriminator column="CHILDTYPE"/>
    <property name="aProperty"/>
    <subclass name="SubChild_1" discriminator-value="1"/>
    <subclass name="SubChild_2" discriminator-value="2"/>
  </class>
</hibernate-mapping>

'Parent.hmb.xml'
<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
  "-//Hibernate/Hibernate Mapping DTD 2.0//EN"
  "http://hibernate.sourceforge.net/hibernate-mapping-2.0.dtd">

<hibernate-mapping>
  <class name="Parent">
    <id name="id">
      <generator class="native"/>
    </id>
    <property name="aProperty"/>
    <list name="subChilds_1" lazy="false" cascade="all">
      <key column="parent_id"/>
      <index column="idx"/>
      <one-to-many class="SubChild_1"/>
    </list>
    <list name="subChilds_2" lazy="false" cascade="all">
      <key column="parent_id"/>
      <index column="idx"/>
      <one-to-many class="SubChild_2"/>
    </list>
  </class>
</hibernate-mapping>

Generated SQL when perform session.find()
=========================================
Hibernate: select child0_.id as id__, child0_.idx as idx__, child0_.id as id from Child child0_ where child0_.parent_id=?

There is no 'where CHILDTYPE=?' discriminating clause.


---------------------------------------------------------------------
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-174) Allow multi-column discriminators and other discriminator improvements

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

The following comment has been added to this issue:

     Author: Tom Sedge
    Created: Thu, 10 Jul 2003 8:43 AM
       Body:
I forgot to say that the single-column discriminator is presumed by the persister/loader architecture via getDiscriminatorColumnName().  This is one of the reasons it is so difficult to extend this at the moment.

What about a completely separate and extensible discriminator sub-system - would something like this be feasible?  (I lack sufficient in-depth knowledge of Hibernate's sourcecode to judge this myself).
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-174
    Summary: Allow multi-column discriminators and other discriminator improvements
       Type: Improvement

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
   Versions:
             2.0.1

   Assignee: 
   Reporter: Tom Sedge

    Created: Thu, 10 Jul 2003 8:40 AM
    Updated: Thu, 10 Jul 2003 8:40 AM
Environment: N/A

Description:
The extensible persister system in Hibernate is very nice and useful and custom discriminator types can be created via a custom Hibernate
type and new persister.  However, the structure of the discriminator is not wholly under the persister's control.

Recently I've come across a number of situations where mapping legacy data models requires one of:

1. A joined-subclass discriminator where the discriminator in the parent table may be in more than one column (e.g. Column A not null implies Class A, Column B not null implies Class B).

2. A joined-subclass discriminator where the discriminator is not the primary key of the parent table.

3. A joined-subclass discriminator where force="true" can be applied.

4. Nesting a table-per-class-hierachy within joined-subclass (e.g. Table A contains parent class A, Table B joins to that table for class B and also contains Class C via a discriminator in Table B) & vice-versa.

5. Generating a discriminator from multiple columns via a general expression.

As far as I can see (2) is not possible as there is no syntax support for this in the XML document (i.e. specify column in parent in <key> directive).  (1) follows from (2) - requires specifying the column.  (3) doesn't seem to be availale for joined-subclasses but is important since only some of the data in table may be needed.  (4) looks completely ruled out by the DTD.  (5) looks difficult, though a custom persister might be able to fudge it.

What are the chances of Hibernate supporting any of the above?  What is the level of difficulty involved in each one (I may be able to help).

For the record, these seem to me to be reasonable requirements and would greatly ease working with difficult legacy data model - which in my experience are more common than greenfield sites.


 


---------------------------------------------------------------------
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-174) Allow multi-column discriminators and other discriminator improvements

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-174
    Summary: Allow multi-column discriminators and other discriminator improvements
       Type: Improvement

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
   Versions:
             2.0.1

   Assignee: 
   Reporter: Tom Sedge

    Created: Thu, 10 Jul 2003 8:40 AM
    Updated: Thu, 10 Jul 2003 8:40 AM
Environment: N/A

Description:
The extensible persister system in Hibernate is very nice and useful and custom discriminator types can be created via a custom Hibernate
type and new persister.  However, the structure of the discriminator is not wholly under the persister's control.

Recently I've come across a number of situations where mapping legacy data models requires one of:

1. A joined-subclass discriminator where the discriminator in the parent table may be in more than one column (e.g. Column A not null implies Class A, Column B not null implies Class B).

2. A joined-subclass discriminator where the discriminator is not the primary key of the parent table.

3. A joined-subclass discriminator where force="true" can be applied.

4. Nesting a table-per-class-hierachy within joined-subclass (e.g. Table A contains parent class A, Table B joins to that table for class B and also contains Class C via a discriminator in Table B) & vice-versa.

5. Generating a discriminator from multiple columns via a general expression.

As far as I can see (2) is not possible as there is no syntax support for this in the XML document (i.e. specify column in parent in <key> directive).  (1) follows from (2) - requires specifying the column.  (3) doesn't seem to be availale for joined-subclasses but is important since only some of the data in table may be needed.  (4) looks completely ruled out by the DTD.  (5) looks difficult, though a custom persister might be able to fudge it.

What are the chances of Hibernate supporting any of the above?  What is the level of difficulty involved in each one (I may be able to help).

For the record, these seem to me to be reasonable requirements and would greatly ease working with difficult legacy data model - which in my experience are more common than greenfield sites.


 


---------------------------------------------------------------------
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-172) multiple discriminator-value for subclass

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

The following comment has been added to this issue:

     Author: Tom Sedge
    Created: Thu, 10 Jul 2003 8:23 AM
       Body:
I recently wrote a custom persister that allowed this.  I allowed lists (13,14), ranges (20-31), plus greater than and less than options.

Basically I allowed a comma-separated list in the discriminator and created a custom type to map the discriminator as a string.  Then, inside my custom persister I converted this to numeric values and stored my own mapping of discriminator to subclass

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

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-172
    Summary: multiple discriminator-value for subclass
       Type: New Feature

     Status: Unassigned
   Priority: Minor

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0.2

   Assignee: 
   Reporter: Ludovic Orban

    Created: Thu, 10 Jul 2003 1:59 AM
    Updated: Thu, 10 Jul 2003 1:59 AM
Environment: any/all

Description:
It would be nice to allow a class or a subclass to have multiple possible discriminator values.

Hibernate would need to map the same subclass to multiple values and the resulting unmapped values to the root class (or some other subclass), using a mapping that could look like this:


<class name="pkg.RootObject" table="SOME_TABLE" discriminator-value="*">

...

    <discriminator column="TYPE" type="integer" />

...

    <subclass name="pkg.SubClassA" discriminator-value="12, 13">



    <subclass name="pkg.SubClassB" discriminator-value="45">

</class>



---------------------------------------------------------------------
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-173) Access to <meta> with the API

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-173
    Summary: Access to <meta> with the API
       Type: Improvement

     Status: Unassigned
   Priority: Minor

    Project: Hibernate2
 Components: 
             core

   Assignee: 
   Reporter: xfgdf

    Created: Thu, 10 Jul 2003 7:21 AM
    Updated: Thu, 10 Jul 2003 7:21 AM

Description:
It would be great to access to the <meta> elements with the API. Something like :

String ClassMetaData.getClassMetaTag(String key);
String ClassMetaData.getPropertyMetaTag(String property, String key);
String ClassMetaData.getCollectionMetaTag(String role, String key);
...

May be their not all usefull. This would help to make our own generator (form JSP, personnal toString(), XML, etc). Hibernate mapping files could be use this way as a repository for all kind of metadata.

        Adrien






---------------------------------------------------------------------
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-172) multiple discriminator-value for subclass

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-172
    Summary: multiple discriminator-value for subclass
       Type: New Feature

     Status: Unassigned
   Priority: Minor

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0.2

   Assignee: 
   Reporter: Ludovic Orban

    Created: Thu, 10 Jul 2003 1:59 AM
    Updated: Thu, 10 Jul 2003 1:59 AM
Environment: any/all

Description:
It would be nice to allow a class or a subclass to have multiple possible discriminator values.

Hibernate would need to map the same subclass to multiple values and the resulting unmapped values to the root class (or some other subclass), using a mapping that could look like this:


<class name="pkg.RootObject" table="SOME_TABLE" discriminator-value="*">

...

    <discriminator column="TYPE" type="integer" />

...

    <subclass name="pkg.SubClassA" discriminator-value="12, 13">



    <subclass name="pkg.SubClassB" discriminator-value="45">

</class>



---------------------------------------------------------------------
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-171) Ability to generate map of 2 components of the same type in one class using xdoclet

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-171
    Summary: Ability to generate map of 2 components of the same type in one class using xdoclet
       Type: Bug

     Status: Unassigned
   Priority: Minor

    Project: Hibernate2
 Components: 
             toolset
   Versions:
             2.0.1

   Assignee: 
   Reporter: Dan Tran

    Created: Thu, 10 Jul 2003 12:32 AM
    Updated: Thu, 10 Jul 2003 12:32 AM
Environment: xdoclet 1.2 beta3

Description:
I would like to define 2 components of the same type in one class.
Current Hibernte-xdoclet does not support this configuration.

Here is an example with my desired map output

    <component name="name" class="org.glvnsjc.model.Name">
      <property name="lastNameRaw"   column="lastName" type="string"/>
      <property name="middleNameRaw" column="middleName" type="string"/>
      <property name="firstNameRaw"  column="firstName" type="string"/>
    </component>
    <component name="parentName" class="org.glvnsjc.model.Name">
      <property name="lastNameRaw"    column="parentLastName"
type="string"/>
      <property name="middleNameRaw"  column="parentMiddleName"
type="string"/>
      <property name="firstNameRaw"   column="parentFirstName"
type="string"/>
    </component>



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