hibernate-issues — Hibernate JIRA Notifications

[Hibernate-issues] [Hibernate-JIRA] Assigned: (HB-591) Extra documentation to indicate multi-column indexes are possible

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

Message:

   The following issue has been re-assigned.

   Assignee: Christian Bauer (mailto:chr...@hi...)
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-591
    Summary: Extra documentation to indicate multi-column indexes are possible
       Type: Patch

     Status: Open
   Priority: Minor

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: Hibernate2

   Assignee: Christian Bauer
   Reporter: Francois Beausoleil

    Created: Wed, 31 Dec 2003 7:53 AM
    Updated: Sat, 10 Jan 2004 2:49 AM
Environment: Tested on Hibernate 2.0.2

Description:
The following patch adds documentation explaining to the user that it is possible to have the SchemaExport tool automatically create indexes.

This patch is a followup to the following thread:
http://forum.hibernate.org/viewtopic.php?t=926694

Index: doc/reference/src/basic_or_mapping.xml
===================================================================
RCS file: /cvsroot/hibernate/Hibernate2/doc/reference/src/basic_or_mapping.xml,v
retrieving revision 1.30
diff -u -r1.30 basic_or_mapping.xml
--- doc/reference/src/basic_or_mapping.xml	1 Aug 2003 16:33:06 -0000	1.30
+++ doc/reference/src/basic_or_mapping.xml	31 Dec 2003 13:50:09 -0000
@@ -1718,6 +1718,27 @@
         unique="true"/>
 </property>]]></programlisting>
 
+
+            <para>
+                Finally, it is also possible to have the <literal>SchemaExport</literal> commandline tool generated
+                required indexes automatically.  For this, use the <literal>index</literal> attribute on
+                <literal>&lt;column&gt;</literal> elements.
+            </para>
+
+                <programlisting><![CDATA[<property 
+    name="lastname">
+    <column 
+        name="LASTNAME" 
+        index="by_last_first"/>
+</property>
+
+<property
+    name="firstname">
+    <column
+        name="FIRSTNAME"
+        index="by_last_first"/>
+</property>]]></programlisting>
+
     </sect1>
 
 



---------------------------------------------------------------------
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-598) ehcache is deemed optional, but it is actually required

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

Message:

   The following issue has been closed.

   Resolver: Gavin King
       Date: Sat, 10 Jan 2004 2:47 AM

As far as I'm concerned, it /is/ optional. Max has suggested changing the default hibernate.properties and we might do that.
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-598
    Summary: ehcache is deemed optional, but it is actually required
       Type: Bug

     Status: Closed
   Priority: Major
 Resolution: REJECTED

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1

   Assignee: 
   Reporter: Attila Szegedi

    Created: Sun, 4 Jan 2004 10:29 AM
    Updated: Sat, 10 Jan 2004 2:47 AM

Description:
ehcache.jar is specified as "optional" in lib/README.txt. However if Hibernate is initialized without specifying explicit value for "hibernate.cache.provider_class", it will default to "net.sf.ehcache.hibernate.Provider", and a ClassNotFoundException will be thrown if ehcache.jar is not present. Either improve the documentation to say something like:
 "required by default, except if you specify another cache provider"
or alternatively work around to remove this implicit reqiured dependency.


---------------------------------------------------------------------
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-603) Add a hook to get at configured Interceptor on Session

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

Message:

   The following issue has been closed.

   Resolver: Gavin King
       Date: Sat, 10 Jan 2004 2:45 AM

I don't like the idea of this.
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-603
    Summary: Add a hook to get at configured Interceptor on Session
       Type: Improvement

     Status: Closed
   Priority: Minor
 Resolution: REJECTED

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: Hibernate2
   Versions:
             2.1.1

   Assignee: 
   Reporter: Edina Pimp

    Created: Mon, 5 Jan 2004 11:23 AM
    Updated: Sat, 10 Jan 2004 2:45 AM

Description:
It would be nice to have a handle to the configured Interceptor on the Session.  Having one would allow runtime plugability of different Interceptors.


---------------------------------------------------------------------
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-604) problems upgrading using a criteria with postgresql 7.4

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

Message:

   The following issue has been closed.

   Resolver: Gavin King
       Date: Sat, 10 Jan 2004 2:44 AM

This problem does not sound like it is related to Hibernate.
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-604
    Summary: problems upgrading using a criteria with postgresql 7.4
       Type: Bug

     Status: Closed
   Priority: Major
 Resolution: REJECTED

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1.1

   Assignee: 
   Reporter: Matt Ho

    Created: Mon, 5 Jan 2004 11:49 AM
    Updated: Sat, 10 Jan 2004 2:44 AM
Environment: sun jdk 1.4.2_03, postgresql 7.4, hibernate 2.1.1

Description:
Using Hibernate 2.1.1 and PostgreSQL 7.4, I'm trying to use the Criteria API to do a SELECT ... FOR UPDATE on a given table. If I include a

criteria.setLockMode(LockMode.UPGRADE);


I get the following Exception

132531 [tcpConnection-8080-2] WARN util.JDBCExceptionReporter  - SQL Error: 0, SQLState: 0A000
132531 [tcpConnection-8080-2] ERROR util.JDBCExceptionReporter  - ERROR: DECLARE CURSOR ... FOR UPDATE is not supported

132531 [tcpConnection-8080-2] WARN util.JDBCExceptionReporter  - SQL Error: 0, SQLState: 0A000
132531 [tcpConnection-8080-2] ERROR util.JDBCExceptionReporter  - ERROR: DECLARE CURSOR ... FOR UPDATE is not supported


However, if I remove the criteria.setLockMode() statement, life is good. I used p6spy to check the SQL generated when the setLockMode(LockMode.UPGRADE) is used and it looks fine. I copied it into a SquirrelSQL window and the SQL executes fine. The problem appears to occur after the response comes back.

I've attached a test case that reproduces the problem.


---------------------------------------------------------------------
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-608) Allow criteria queries on abstract classes from table-per-concrete-class mappings

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

The following comment has been added to this issue:

     Author: Gavin King
    Created: Sat, 10 Jan 2004 2:02 AM
       Body:
This looks quite reasonable, actually. We should integrate this.
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-608
    Summary: Allow criteria queries on abstract classes from table-per-concrete-class mappings
       Type: Improvement

     Status: Open
   Priority: Minor

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1.1

   Assignee: Gavin King
   Reporter: Shorn Tolley

    Created: Mon, 5 Jan 2004 11:09 PM
    Updated: Sat, 10 Jan 2004 2:02 AM
Environment: Hibernate 2.1.1, Ingres 2.6 SP2

Description:
I'm mapping a part of my domain model using the table-per-concrete-class strategy.  I need to use hibernate's "implicit polymorphism" feature to query on the abstract class in the hierarchy to return specific instances of the class regardless of their concrete type.

I can do it using the HQL query mechanism (as long as I fully qualify the name of the abstract class), but when I try to use the Criteria query mechanism I get a mapping exception with a "No persisten for: <Classname>" type message.

The relevant section in the 2.1.1 documentation is "Chapter 16 Inheritance mappings".

I posted my problem in a forum topic and am raising this issue as a result of instructions given by the hibernate team: http://forum.hibernate.org/viewtopic.php?t=926608

Even if you don't want to implement the functionality I'm talking about (or want to delay it's implementation for a while), it might be a good idea to update the table in the limitations section for the "polymorphic load()/get()" column that says "use a query" to note that you can't use a criteria query.

It also might be worth mentioning that you need to use the fully qualified classname of the abstract class in the HQL query.



---------------------------------------------------------------------
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-609) replicate() with joined-subclass

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

Message:

   The following issue has been closed.

   Resolver: Gavin King
       Date: Sat, 10 Jan 2004 1:59 AM

fixed in cvs
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-609
    Summary: replicate() with joined-subclass
       Type: Bug

     Status: Closed
   Priority: Major
 Resolution: FIXED

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: Hibernate2
   Fix Fors:
             2.1.2
   Versions:
             2.1.1

   Assignee: Gavin King
   Reporter: Greg Barton

    Created: Tue, 6 Jan 2004 12:53 PM
    Updated: Sat, 10 Jan 2004 1:59 AM
Environment: Hibernate 2.1.1, Postgres 7.4

Description:
Attempt to call Session.replicate() on a persistent object mapped using joined-subclass.  A net.sf.hibernate.JDBCException is thrown because HIbernate attempts to access the "version" column in the underlying table.  That column is only present in the superclass table of the class being being replicated.

Exception generated:
net.sf.hibernate.JDBCException: could not retrieve version: [***id of object***]
        at net.sf.hibernate.persister.AbstractEntityPersister.getCurrentVersion(AbstractEntityPersister.java:1141)
        at net.sf.hibernate.impl.SessionImpl.replicate(SessionImpl.java:3698)
        at.... 


---------------------------------------------------------------------
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-487) Unecessary object creation in CharBooleanType

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

Message:

   The following issue has been closed.

   Resolver: Gavin King
       Date: Sat, 10 Jan 2004 1:49 AM

In the interests of back-compatibility I think we should not throw this exception.
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-487
    Summary: Unecessary object creation in CharBooleanType
       Type: Patch

     Status: Closed
   Priority: Trivial
 Resolution: FIXED

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1 beta 6

   Assignee: Gavin King
   Reporter: Bertrand Renuart

    Created: Fri, 21 Nov 2003 1:51 PM
    Updated: Sat, 10 Jan 2004 1:49 AM

Description:
Unecessary objects are created when converting the data retrieved from the resultset to a Boolean.

Original code:
--------------
  return new Boolean( code.toUpperCase().equals( getTrueString() ) );

Explanation:
------------
- code.toUpperCase() creates a new String - code.equalsIgnoreCase() should be used instead

- new Boolean() creates a new Boolean instance where Boolean.TRUE | FALSE could be used

This would lead to the following code:

  if ( code.equalsIgnoreCase(getTrueString())) {
    return Boolean.TRUE;
  }
  else {
    return Boolean.FALSE;
  }

A bit more efficient ;-)


Note: what should we do if code != getFalseString()? Should we throw an SQLException ?




---------------------------------------------------------------------
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-483) Odd behavior from query cache startup

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

Message:

   The following issue has been closed.

   Resolver: Gavin King
       Date: Sat, 10 Jan 2004 1:47 AM

I fixed this a while ago.
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-483
    Summary: Odd behavior from query cache startup
       Type: Bug

     Status: Closed
   Priority: Minor
 Resolution: FIXED

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1 beta 6

   Assignee: Gavin King
   Reporter: Loren Rosen

    Created: Thu, 20 Nov 2003 12:16 PM
    Updated: Sat, 10 Jan 2004 1:47 AM
Environment: Mac OSX 10.1.5
JDK 1.3.1

Description:
It seems that it takes 3 query calls before the query cache is propery initialized and starts caching queries. I'll grant this isn't so critical for overall effectiveness of the cache, but it will confuse someone who tries to write a very simple program to demonstrate the operation of the query cache.

For example, if the gist of main() is this:
        Session sess;
        Long l = new Long(79);

        for (int i=1;i<=5;i++) {
            System.out.println("-----run query iteration " + i + " --------------");
            sess = sessions.openSession();
            runQuery(l, sess);
            sess.close();
        }

and here's the method it calls
    private static void runQuery(Long docId, Session sess) throws Exception {

        Document doc;
        Transaction tx = null;

        try {
            tx = sess.beginTransaction();
            Query q = sess.createQuery("select from Document doc where doc.id=:docId");
            q.setLong("docId", docId.longValue());
            q.setCacheable(true);
            List list = q.list();
            tx.commit();
        } catch (Exception e) {
            tx.rollback();
            throw e;
        }

    }

If you run this with query logging enabled, you'll see that only the 4th and 5th iterations of loop succeed in getting the query results from the query cache.

I've traced through the code, and I think I know what's going on. It's a bit complicated to explain, but I'll be happy to write it down if anyone wants to try fixing the problem.


---------------------------------------------------------------------
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-39) JMX config

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

Message:

   The following issue has been closed.

   Resolver: Gavin King
       Date: Sat, 10 Jan 2004 1:46 AM

This is a bit ancient and obsolete.
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-39
    Summary:  JMX config
       Type: Patch

     Status: Closed
   Priority: Major
 Resolution: WON'T FIX

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: Hibernate2

   Assignee: Gavin King
   Reporter: Max Rydahl Andersen

    Created: Sat, 3 May 2003 10:24 AM
    Updated: Sat, 10 Jan 2004 1:46 AM

Description:
JMX config
A small extension in HibernateServiceMBean so you 
can now specify a dynamic set 
of additional properties in hibernate-service.xml. 

e.g.: 
<?xml version="1.0" encoding="UTF-8"?> 
<service> 
<mbean 
code="cirrus.hibernate.jmx.HibernateService" 
name="jboss.jca:service=Hibernate"> 

<depends>jboss.jca:service=RARDeployer</depends> 
<attribute 
name="JndiName">java:/HibernateFactory</attribute> 
... 
<attribute name="AdditionalProperties"> 
<properties> 
<property 
name="hibernate.transaction.factory_class" 
value="cirrus.hibernate.transaction.JTATransactionFactor 
y"/> 
... 
</properties> 
</attribute> 
</mbean> 
</service> 

http://sourceforge.net/tracker/index.php?func=detail&aid=684379&group_id=40712&atid=428710


---------------------------------------------------------------------
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-605) No "duplicate import" error on DTD violation - includes Patch

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

Message:

   The following issue has been closed.

   Resolver: Gavin King
       Date: Sat, 10 Jan 2004 1:41 AM

Applied this patch.
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-605
    Summary: No "duplicate import" error on DTD violation - includes Patch
       Type: Improvement

     Status: Closed
   Priority: Major
 Resolution: FIXED

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1.1

   Assignee: Gavin King
   Reporter: Michael Gloegl

    Created: Mon, 5 Jan 2004 4:41 PM
    Updated: Sat, 10 Jan 2004 1:41 AM
Environment: Hibernate 2.1.1

Description:
When a mapping document violates the DTD, Hibernate will log the error and nertheless add the mapping to the session factory. Later on a "duplicate import" error gets produced when Hibernate tries to add the same mapping again. This patch intends to solve this by not adding the mapping if there is an error during parsing.


---------------------------------------------------------------------
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-597) Criteria API - NOT IN not working on MySQL

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

Message:

   The following issue has been closed.

   Resolver: Gavin King
       Date: Sat, 10 Jan 2004 1:32 AM

Since I believe that this is specific to MySQL, I added an ugly test for MySQL. Should really change it to be done on Dialect, I suppose.
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-597
    Summary: Criteria API - NOT IN not working on MySQL
       Type: Bug

     Status: Closed
   Priority: Major
 Resolution: FIXED

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: Hibernate2
 Components: 
             core
   Fix Fors:
             2.1.2
   Versions:
             2.1.1

   Assignee: Gavin King
   Reporter: Michael Gloegl

    Created: Fri, 2 Jan 2004 5:42 PM
    Updated: Sat, 10 Jan 2004 1:32 AM
Environment: Hibernate 2.1.1, MySQL

Description:
On MySQL the SQL generated by a Criteria query like

Object o =
	session
		.createCriteria(Event.class)
		.add(Expression.not(Expression.in("id", id_values)))
		.uniqueResult();

does not work. Hibernate generates a SQL like 

SELECT * FROM Event WHERE NOT id IN ( 1, 2, 3, 4, 5  ) 

This should work, but MySQL does not get the operator precedences right. This works by using explicit brackets, or by placing the NOT after the column name.

I attatch some possible patches 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] Closed: (HB-607) <composite-element> does not accept <any> in it

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

Message:

   The following issue has been closed.

   Resolver: Gavin King
       Date: Sat, 10 Jan 2004 1:23 AM

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

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-607
    Summary: <composite-element> does not accept <any> in it
       Type: Bug

     Status: Closed
   Priority: Major
 Resolution: FIXED

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: Hibernate2
   Versions:
             2.1

   Assignee: Gavin King
   Reporter: Sankara N Alwar

    Created: Mon, 5 Jan 2004 8:10 PM
    Updated: Sat, 10 Jan 2004 1:23 AM
Environment: Hibernate 2.1 Final, Oralce 8.1.7, Windows 2000

Description:
<composite-element> does not accept <any> in it. I get the following error if I add any inside <composite-element>: 

ERROR [Thread-4] 2003-12-23 23:42:18,735 - net.sf.hibernate.util.XMLHelper - Error parsing XML: XML InputStream(180) The content of element type "composite-element" must match "(parent?,(property|many-to-one|nested-composite-element)*)". 

Even I verified the dtd, it doesn't accept it. Here is my mapping: 

<set name="Persons" table="groupmembership" lazy="true" inverse="true"> 
<key column="group_id"/> 
<composite-element class="net.sf.hibernate.examples.quickstart.GroupMembership"> 
<any name="members" id-type="string" meta-type="net.sf.hibernate.examples.quickstart.GroupTypeMapper"> 
<column name="child_type"/> 
<column name="child_id"/> 
</any> 
</composite-element> 
</set> 




---------------------------------------------------------------------
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-606) Add nested component in Query By Example

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

The following comment has been added to this issue:

     Author: Gavin King
    Created: Sat, 10 Jan 2004 1:16 AM
       Body:
Emmanuel, looks like the diff is broken - I can't see exactly which lines changed....
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-606
    Summary: Add nested component in Query By Example
       Type: Improvement

     Status: Open
   Priority: Major

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1.1

   Assignee: Gavin King
   Reporter: Emmanuel Bernard

    Created: Mon, 5 Jan 2004 4:49 PM
    Updated: Sat, 10 Jan 2004 1:16 AM
Environment: Head of 2.1 branch 01/06/2003 00h00 GMT+1

Description:
Add nested component parsing during Query By 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-611) Session.load() retrieves different Object instances when String keys are used

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

The following comment has been added to this issue:

     Author: Scott Russell
    Created: Fri, 9 Jan 2004 10:04 PM
       Body:
Ok, that works. If anyone else runs into similar problems, the code for a String type that trims Strings is:

public class TrimStringType extends StringType
{
    public Object get(ResultSet rs, String name) throws SQLException
    {
        String s = rs.getString(name);

        return s != null ? s.trim() : null;
    }

    public Object stringToObject(String xml) throws Exception
    {
        return xml != null ? xml.trim() : null;
    }

    public boolean equals(Object x, Object y)
    {
        if (x == null && y == null) return true;
        if (x == null || y == null) return false;

        return ((String) x).trim().equals(((String) y).trim());
    }

    public String toString(Object value)
    {
        return ((String) value).trim();
    }

    public Object fromStringValue(String xml)
    {
        return xml.trim();
    }
}

I have found that JDBC often pads fixed length char fields with extra whitespace, so this could be useful.

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

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-611
    Summary: Session.load() retrieves different Object instances when String keys are used
       Type: Bug

     Status: Closed
   Priority: Major
 Resolution: REJECTED

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: Hibernate2

   Assignee: 
   Reporter: Scott Russell

    Created: Thu, 8 Jan 2004 11:59 PM
    Updated: Fri, 9 Jan 2004 10:04 PM
Environment: HIbernate 2.1, Informix database

Description:
When using Session.load() to load an Object from the database that has a (whitespace-trimmed) string key, different Objects are returned from Parent-Child relationships, which load associated Objects using the full whitespace-padded string key.

I noticed this when loading an Child object using Session.load(), and then loading the Parent using Session.load(), and comparing the loaded child with the child in the Parent's collection of children. Although both the loaded Child and the collection-element child refer to the same database record, they exist in the session as different Objects because the former is referenced by its trimmed key, whereas the latter appears to be referenced by its full length key (ie. as loaded from the database column, padded with empty spaces). This causes countless problems, as one naturally expects that the same object would be used within the same session.

eg. 

Child c1 = (Child) Session.load(Child.class, "A");
c1.setValue("a_value");

Parent p = (Parent) Session.load(Parent.class, "B");

Child c2 = p.getChild("A");  // returns null
Child c3 = p.getChild("A       ");  // returns expected child

c3.getValue();   // Returns original loaded value, not "a_value",
                 // as one would expect




---------------------------------------------------------------------
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-611) Session.load() retrieves different Object instances when String keys are used

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

The following comment has been added to this issue:

     Author: Gavin King
    Created: Fri, 9 Jan 2004 9:54 PM
       Body:
quote:
> use a custom type
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-611
    Summary: Session.load() retrieves different Object instances when String keys are used
       Type: Bug

     Status: Closed
   Priority: Major
 Resolution: REJECTED

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: Hibernate2

   Assignee: 
   Reporter: Scott Russell

    Created: Thu, 8 Jan 2004 11:59 PM
    Updated: Fri, 9 Jan 2004 9:54 PM
Environment: HIbernate 2.1, Informix database

Description:
When using Session.load() to load an Object from the database that has a (whitespace-trimmed) string key, different Objects are returned from Parent-Child relationships, which load associated Objects using the full whitespace-padded string key.

I noticed this when loading an Child object using Session.load(), and then loading the Parent using Session.load(), and comparing the loaded child with the child in the Parent's collection of children. Although both the loaded Child and the collection-element child refer to the same database record, they exist in the session as different Objects because the former is referenced by its trimmed key, whereas the latter appears to be referenced by its full length key (ie. as loaded from the database column, padded with empty spaces). This causes countless problems, as one naturally expects that the same object would be used within the same session.

eg. 

Child c1 = (Child) Session.load(Child.class, "A");
c1.setValue("a_value");

Parent p = (Parent) Session.load(Parent.class, "B");

Child c2 = p.getChild("A");  // returns null
Child c3 = p.getChild("A       ");  // returns expected child

c3.getValue();   // Returns original loaded value, not "a_value",
                 // as one would expect




---------------------------------------------------------------------
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-611) Session.load() retrieves different Object instances when String keys are used

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

The following comment has been added to this issue:

     Author: Scott Russell
    Created: Fri, 9 Jan 2004 9:18 PM
       Body:
No, not "of course"

JDBC tends to return Strings from queries padded to the full char column length (in fixed-length fields), which causes equality problems for Java (where "A" and "A  " are not equal) but not the RDBMS. Often, using straight JDBC one has to trim the strings returned to get around this.

Using a wrapper class as the key is a possibility, but it introduces an element of complexity that most new users will not initially be prepared for. The implication of using a String key in a OR mapping tool is that it would work as it works in the RDBMS (ie. that trimmed and non-trimmed String keys refer to the same entity)




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

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-611
    Summary: Session.load() retrieves different Object instances when String keys are used
       Type: Bug

     Status: Closed
   Priority: Major
 Resolution: REJECTED

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: Hibernate2

   Assignee: 
   Reporter: Scott Russell

    Created: Thu, 8 Jan 2004 11:59 PM
    Updated: Fri, 9 Jan 2004 9:18 PM
Environment: HIbernate 2.1, Informix database

Description:
When using Session.load() to load an Object from the database that has a (whitespace-trimmed) string key, different Objects are returned from Parent-Child relationships, which load associated Objects using the full whitespace-padded string key.

I noticed this when loading an Child object using Session.load(), and then loading the Parent using Session.load(), and comparing the loaded child with the child in the Parent's collection of children. Although both the loaded Child and the collection-element child refer to the same database record, they exist in the session as different Objects because the former is referenced by its trimmed key, whereas the latter appears to be referenced by its full length key (ie. as loaded from the database column, padded with empty spaces). This causes countless problems, as one naturally expects that the same object would be used within the same session.

eg. 

Child c1 = (Child) Session.load(Child.class, "A");
c1.setValue("a_value");

Parent p = (Parent) Session.load(Parent.class, "B");

Child c2 = p.getChild("A");  // returns null
Child c3 = p.getChild("A       ");  // returns expected child

c3.getValue();   // Returns original loaded value, not "a_value",
                 // as one would expect




---------------------------------------------------------------------
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-613) Problem with null composite-elements

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

Message:

   The following issue has been closed.

   Resolver: Gavin King
       Date: Fri, 9 Jan 2004 8:59 PM

This is consistent with the documented null value behavior of components.
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-613
    Summary: Problem with null composite-elements
       Type: Bug

     Status: Closed
   Priority: Minor
 Resolution: REJECTED

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1 final

   Assignee: 
   Reporter: William Drai

    Created: Fri, 9 Jan 2004 9:52 AM
    Updated: Fri, 9 Jan 2004 8:59 PM
Environment: Hibernate 2.1, MySQL 4.1.1

Description:
I have a mapping like this :

<class name="Foo">
  <id  ../>

  <map name="elements" table="ELEMENTS">
    <key column="FOO_ID" />
    <index column="ELEMENT_ID" />
    <composite-element class="Element">
      <property name="prop1" />
      <property name="prop2" />
    </composite-element>
  </map>
</class>

If I store an instance of Foo with one element in the map where prop1 and prop2 are null, all is ok in the database :

ELEMENT_ID | PROP1 | PROP2
 "element" |  null |  null

When I load this instance of Foo later, I get the "elements" map, but the entry has a key "element" and a null value, instead having a new empty Element instance.


William




---------------------------------------------------------------------
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-534) Table schema use in DatabaseMetadata

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

Message:

   The following issue has been closed.

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

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-534
    Summary: Table schema use in DatabaseMetadata
       Type: Bug

     Status: Closed
   Priority: Major
 Resolution: DUPLICATE

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1 beta 4

   Assignee: 
   Reporter: Adrien

    Created: Tue, 9 Dec 2003 10:55 AM
    Updated: Fri, 9 Jan 2004 8:57 PM
Environment: Hibernate 2.1 beta 4, Oracle 8i

Description:

When using SchemaUpdate, the DatabaseMetaData.getTableMetadata() looks for a table with the correct table name in any database schema and it take the first one it found. This behavior is uncorrect if I have a table  existing in different schemas. 

The correct behavior would be to first look in the schema with the login name and after in any schema.

  user1.article
  user2.article

I connected whith user2, DatabaseMetaData should first look for user2.article, then if not found to %.article.

  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] Closed: (HB-612) SchemaExport: DB2 CLOB fails

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

Message:

   The following issue has been closed.

   Resolver: Gavin King
       Date: Fri, 9 Jan 2004 8:56 PM

sql-type="CLOB(234243)"
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-612
    Summary: SchemaExport: DB2 CLOB fails
       Type: Bug

     Status: Closed
   Priority: Blocker
 Resolution: REJECTED

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: Hibernate2
 Components: 
             toolset
   Versions:
             2.1

   Assignee: 
   Reporter: Jan Riis

    Created: Fri, 9 Jan 2004 8:02 AM
    Updated: Fri, 9 Jan 2004 8:56 PM
Environment: DB2 vers. 7.2 on Win XP

Description:
When using DB2 dialect, the generated schema (DDL)for CLOB fields does not include a "length" specification.

    <class name="dk.acure.journal.model.Skema">
...
        <property name="xml" type="string" length="256000">
          <column name="xml" sql-type="CLOB"/>
        </property>
    </class>

generates:

create table Skema (
...
  xml CLOB,
);

But should be:
  xml CLOB (256000)

Length is mandatory in DB2 (as far as I can see)



---------------------------------------------------------------------
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-611) Session.load() retrieves different Object instances when String keys are used

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

Message:

   The following issue has been closed.

   Resolver: Gavin King
       Date: Fri, 9 Jan 2004 8:56 PM

um ... of course ....

use a custom type
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-611
    Summary: Session.load() retrieves different Object instances when String keys are used
       Type: Bug

     Status: Closed
   Priority: Major
 Resolution: REJECTED

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: Hibernate2

   Assignee: 
   Reporter: Scott Russell

    Created: Thu, 8 Jan 2004 11:59 PM
    Updated: Fri, 9 Jan 2004 8:56 PM
Environment: HIbernate 2.1, Informix database

Description:
When using Session.load() to load an Object from the database that has a (whitespace-trimmed) string key, different Objects are returned from Parent-Child relationships, which load associated Objects using the full whitespace-padded string key.

I noticed this when loading an Child object using Session.load(), and then loading the Parent using Session.load(), and comparing the loaded child with the child in the Parent's collection of children. Although both the loaded Child and the collection-element child refer to the same database record, they exist in the session as different Objects because the former is referenced by its trimmed key, whereas the latter appears to be referenced by its full length key (ie. as loaded from the database column, padded with empty spaces). This causes countless problems, as one naturally expects that the same object would be used within the same session.

eg. 

Child c1 = (Child) Session.load(Child.class, "A");
c1.setValue("a_value");

Parent p = (Parent) Session.load(Parent.class, "B");

Child c2 = p.getChild("A");  // returns null
Child c3 = p.getChild("A       ");  // returns expected child

c3.getValue();   // Returns original loaded value, not "a_value",
                 // as one would expect




---------------------------------------------------------------------
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-612) SchemaExport: DB2 CLOB fails

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

The following comment has been added to this issue:

     Author: Jan Riis
    Created: Fri, 9 Jan 2004 11:21 AM
       Body:
See https://aurora.vcu.edu/db2help/db2s0/frame3.htm#sqls0621 for further assistance
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-612
    Summary: SchemaExport: DB2 CLOB fails
       Type: Bug

     Status: Unassigned
   Priority: Blocker

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: Hibernate2
 Components: 
             toolset
   Versions:
             2.1

   Assignee: 
   Reporter: Jan Riis

    Created: Fri, 9 Jan 2004 8:02 AM
    Updated: Fri, 9 Jan 2004 11:21 AM
Environment: DB2 vers. 7.2 on Win XP

Description:
When using DB2 dialect, the generated schema (DDL)for CLOB fields does not include a "length" specification.

    <class name="dk.acure.journal.model.Skema">
...
        <property name="xml" type="string" length="256000">
          <column name="xml" sql-type="CLOB"/>
        </property>
    </class>

generates:

create table Skema (
...
  xml CLOB,
);

But should be:
  xml CLOB (256000)

Length is mandatory in DB2 (as far as I can see)



---------------------------------------------------------------------
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-614) "Create only" option for SchemaExport

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

The following issue has been updated:

    Updater: Dennis Carroll (mailto:Den...@do...)
       Date: Fri, 9 Jan 2004 10:22 AM
    Changes:
             Attachment changed to SchemaExportTask.java
    ---------------------------------------------------------------------
For a full history of the issue, see:

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

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

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-614
    Summary: "Create only" option for SchemaExport
       Type: Improvement

     Status: Unassigned
   Priority: Minor

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: Hibernate2
 Components: 
             toolset
   Versions:
             2.1.1

   Assignee: 
   Reporter: Dennis Carroll

    Created: Fri, 9 Jan 2004 10:22 AM
    Updated: Fri, 9 Jan 2004 10:22 AM
Environment: 2.1

Description:
I have added a create parameter to the SchemaExport ant task to generate the create ddl without the drop ddl.  I have no idea if this is useful to anyone else, and the semantics are a little confusing, but here it is anyway.



---------------------------------------------------------------------
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-614) "Create only" option for SchemaExport

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

The following issue has been updated:

    Updater: Dennis Carroll (mailto:Den...@do...)
       Date: Fri, 9 Jan 2004 10:22 AM
    Changes:
             Attachment changed to SchemaExport.java
    ---------------------------------------------------------------------
For a full history of the issue, see:

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

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

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-614
    Summary: "Create only" option for SchemaExport
       Type: Improvement

     Status: Unassigned
   Priority: Minor

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: Hibernate2
 Components: 
             toolset
   Versions:
             2.1.1

   Assignee: 
   Reporter: Dennis Carroll

    Created: Fri, 9 Jan 2004 10:22 AM
    Updated: Fri, 9 Jan 2004 10:22 AM
Environment: 2.1

Description:
I have added a create parameter to the SchemaExport ant task to generate the create ddl without the drop ddl.  I have no idea if this is useful to anyone else, and the semantics are a little confusing, but here it is anyway.



---------------------------------------------------------------------
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] Shared References Error

[Mike P. <mi...@es...>]

Hi,

I am getting this error now when I try to execute a query.

I have walked into the SessionImpl in my debugger and it appears that =
the collection in question is collection of dependent objects that are =
of the same type of the host object. IE: Russian Dolls contain many =
Russian Dolls. =20

I would swear that this has been working for a long time, I dont know =
what I did to introduce this problem. Since getting this problem I have =
upgraded to 2.1.1 and am using the default cache still... I think its =
called EHCache.

I also attached my hbm mapping file... The collection that the debugger =
pointed me to was called dependents... In my situation Cases have many =
dependents which are also Cases....

I guess I am trying to find out who else is sharing this reference? Any =
thoughts?

Here is the stacktrace. The mapping is attached at the end:

net.sf.hibernate.HibernateException: Found shared references to a =
collection
        at =
net.sf.hibernate.impl.SessionImpl.updateReachableCollection(SessionIm
pl.java:2759)
        at =
net.sf.hibernate.impl.FlushVisitor.processCollection(FlushVisitor.jav
a:32)
        at =
net.sf.hibernate.impl.AbstractVisitor.processValue(AbstractVisitor.ja
va:69)
        at =
net.sf.hibernate.impl.AbstractVisitor.processValues(AbstractVisitor.j
ava:36)
        at =
net.sf.hibernate.impl.SessionImpl.flushEntity(SessionImpl.java:2474)
        at =
net.sf.hibernate.impl.SessionImpl.flushEntities(SessionImpl.java:2340
)
        at =
net.sf.hibernate.impl.SessionImpl.flushEverything(SessionImpl.java:22
07)
        at =
net.sf.hibernate.impl.SessionImpl.autoFlushIfRequired(SessionImpl.jav
a:1732)
        at =
net.sf.hibernate.impl.SessionImpl.getQueries(SessionImpl.java:1499)
        at net.sf.hibernate.impl.SessionImpl.find(SessionImpl.java:1464)
        at net.sf.hibernate.impl.SessionImpl.find(SessionImpl.java:1454)
        at net.sf.hibernate.impl.SessionImpl.find(SessionImpl.java:1446)
        at com.esage.agility.DAO.BaseDAO.executeQuery(BaseDAO.java:81)

The simplified mapping file:

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

<hibernate-mapping>
    <class name=3D"com.esage.agility.domain.Case" table=3D"BASE_CASE" =
discriminator-value=3D"B">
        <jcs-cache usage=3D"read-write"/>
        <id column=3D"BASE_CASE_ID" type=3D"long" name=3D"id" =
unsaved-value=3D"null">
            <generator class=3D"identity"/>
        </id>
        <discriminator column=3D"class" type=3D"string"/>
        <set name=3D"dependents" lazy=3D"true" cascade=3D"all">
            <key column=3D"PARENT_CASE_ID"/>
            <one-to-many class=3D"com.esage.agility.domain.Case"/>
        </set>


        <set name=3D"history" lazy=3D"true" cascade=3D"all">
            <key column=3D"CASE_ID"/>
            <one-to-many =
class=3D"com.esage.agility.domain.CaseHistory"/>
        </set>

        <many-to-one name=3D"parent" =
class=3D"com.esage.agility.domain.Case" column=3D"PARENT_CASE_ID"/>
        <subclass name=3D"com.esage.agility.domain.UserStory" =
discriminator-value=3D"U">
            <property name=3D"title" column=3D"TITLE" type=3D"string"/>
        </subclass>
    </class>
</hibernate-mapping>

[Hibernate-issues] [Hibernate-JIRA] Created: (HB-614) "Create only" option for 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-614


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-614
    Summary: "Create only" option for SchemaExport
       Type: Improvement

     Status: Unassigned
   Priority: Minor

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: Hibernate2
 Components: 
             toolset
   Versions:
             2.1.1

   Assignee: 
   Reporter: Dennis Carroll

    Created: Fri, 9 Jan 2004 10:22 AM
    Updated: Fri, 9 Jan 2004 10:22 AM
Environment: 2.1

Description:
I have added a create parameter to the SchemaExport ant task to generate the create ddl without the drop ddl.  I have no idea if this is useful to anyone else, and the semantics are a little confusing, but here it is anyway.



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