Hibernate Community • View topic - Basic Use Case: Parent Child + composite PK + Dynamic Sess

View unanswered posts | View active topics

Board index » Hibernate & Java Persistence » Hibernate Users

All times are UTC - 5 hours [ DST ]

Basic Use Case: Parent Child + composite PK + Dynamic Sess

Page 1 of 1

[ 12 posts ]

Previous topic | Next topic

Author

Message

mschulz

Post subject: Basic Use Case: Parent Child + composite PK + Dynamic Sess

Posted: Wed May 17, 2006 10:46 am

Beginner

Joined: Sat Jan 31, 2004 7:19 pm
Posts: 39

Hibernate version: 3.1.2

I am having some 'fun' with what I think is a very basic use case,
which has been discussed ad nauseum before, for example here:

http://forum.hibernate.org/viewtopic.ph ... ber+childs

Actually I am reusing the example from that thread as much as possible.

My Relational model depends on composite keys for child tables,
where the first part of the primary key is also used as the foreign
key. So the tables are examplified as follows and I can't do anything about that:

Code:

CREATE TABLE Parent (
       parentId             INTEGER NOT NULL
);

ALTER TABLE Parent
       ADD  ( PRIMARY KEY (parentId) ) ; 

CREATE TABLE Child (
       parentId             INTEGER NOT NULL,
       childNumber          INTEGER NOT NULL
);

ALTER TABLE Child
       ADD  ( PRIMARY KEY (parentId, childNumber) ) ;

Simple enough.
Since each Child belongs to a single Parent, I would like to take
advantage of a collection, 'set' or 'bag' for example.
Furthermore, I would very much prefer to have the collection
fully managed from the parent.

I have spent some time on the various variations, so please bear with
me for a second, while I lay them out for you.

For simplicity, I use entity-name so sthat I won't have to write and
provide the corresponding classes.

The simplest variant, on which I would like to solicit comments is:

Code:

<!-- ParentChild, Variant 1 -->

   <class entity-name="Parent" table="Parent">
        <id name="parentId" type="int">
        </id>
        <set name="Children" cascade="all-delete-orphan">
            <key column="parentId" not-null="true" />
            <one-to-many class="Child" />
        </set>
    </class>

    <class entity-name="Child" table="Child">
        <composite-id>
            <key-property name="parentId" type="int"/>
            <key-property name="childNumber" type="int"/>
        </composite-id>
    </class>

This results in the following (again this is a classic, but hang in there):

Code:

1344 [main] ERROR HibernateStore  - Hibernate [odr_Hibernate] ERROR: org.hibernate.MappingException: Repeated column in mapping for entity: Child column: parentId (should be mapped with insert="false" update="false")
org.hibernate.MappingException: Repeated column in mapping for entity: Child column: parentId (should be mapped with insert="false" update="false")
   at org.hibernate.mapping.PersistentClass.checkColumnDuplication(PersistentClass.java:575)
   at org.hibernate.mapping.PersistentClass.checkPropertyColumnDuplication(PersistentClass.java:597)
   at org.hibernate.mapping.PersistentClass.checkColumnDuplication(PersistentClass.java:615)
   at org.hibernate.mapping.PersistentClass.validate(PersistentClass.java:405)
   at org.hibernate.mapping.RootClass.validate(RootClass.java:192)
   at org.hibernate.cfg.Configuration.validate(Configuration.java:984)
   at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1169)
   at dinmar.oacis.hibernate.HibernateStore.getSessionFactory(HibernateStore.java:137)
   at TestParentChild.main(TestParentChild.java:126)

On this, I have two questions:
Q1) What exactly is being checked for duplication here?
As far as I am concerned, I specified the key for the FK in Child,
which would typically be used in a where clause but not as part of
any select list.
Furthermore, why would the separately mapped class Child be
constrained to not 'duplicate' column names used elsewhere in the
mapping?
Q2) Following up on the error message, I tried various places to put
insert="false" update="false" in this mapping, but that appears to
be plain impossible (key and composite-key do not allow these
attributes)

Good advice has been handed out elsewhere, so I'll try an inverse mapping in the next episode, please stay tuned.

Top

mschulz

Post subject:

Posted: Wed May 17, 2006 11:40 am

Beginner

Joined: Sat Jan 31, 2004 7:19 pm
Posts: 39

Following the configuration recommended in the above thread:

Code:

<!-- ParentChild, Variant 2a -->

   <class entity-name="Parent" table="Parent">
        <id name="parentId" type="int">
        </id>
        <set name="Children" inverse="true" cascade="all-delete-orphan">
            <key column="parentId" not-null="true" />
            <one-to-many class="Child" />
        </set>
    </class>

    <class entity-name="Child" table="Child">
        <composite-id>
            <key-many-to-one name="parent" class="Parent" column="parentId"/>
            <key-property name="childNumber" type="int"/>
        </composite-id>
    </class>

using the following code:

Code:

    public Element doExportParents(Session sess) {
        Session sessDom = sess.getSession(EntityMode.DOM4J);

        String qry = null;
       Element prts = new DefaultElement("Parents");
          qry = "from Parent"; 
        Query query = sessDom.createQuery(qry);
        List<Element> res = (List<Element>)query.list();

        for ( Element el : res ) {
           prts.add(el);
        }
        return prts;
    }

I get the following exception:

Code:

4188 [main] ERROR TestParentChild  - Error: 
org.dom4j.IllegalAddException: The node "org.dom4j.tree.DefaultElement@18b3364 [Element: <parent attributes: []/>]" could not be added to the element "Parents" because: The Node already has an existing parent of "Child"
   at org.dom4j.tree.AbstractElement.addNode(AbstractElement.java:1521)
   at org.dom4j.tree.AbstractElement.add(AbstractElement.java:1002)
   at TestParentChild.doExportParents(TestParentChild.java:187)

Hmmh, that got me thinking about the warning in the documentation
about recursive data structures. Should I turn of XML embedding?
Where exactly? In the Child? Sure, add embed-xml="false"...
Oops, we can't have that:

Code:

Caused by: org.xml.sax.SAXParseException: Attribute "embed-xml" must be declared for element type "key-many-to-one".

Q3: What can I do in this mapping to prevent recursion?
I don't want the Parent node added to the child, and either way,
I would expect the Element nodes return from the query to not
have a parent element.
Is the omission of the embed-xml attribute from the key-many-to-one
element accidental or intentional?

OK, admittedly, this _only_ fails due to my insistence on getting
dynamic objects out of it.

Another quick try:

Code:

<!-- ParentChild, Variant 2b -->

   <class entity-name="Parent" table="Parent">
        <id name="parentId" type="int">
        </id>
        <set name="Children" inverse="true" cascade="all-delete-orphan">
            <key column="parentId" not-null="true" />
            <one-to-many class="Child" />
        </set>
    </class>

    <class entity-name="Child" table="Child">
        <composite-id>
            <key-property name="parentId" type="int"/>
            <key-property name="childNumber" type="int"/>
        </composite-id>
        <many-to-one name="Parent" entity-name="Parent" column="parentId" update="false" insert="false"/>
    </class>

Which gives me the same error as above.

In the next episode, we will finally see some XML, and what happens
when trying to persist it. Stay tuned...

Top

bkmr_77

Post subject:

Posted: Wed May 17, 2006 11:59 am

Expert

Joined: Tue Apr 25, 2006 12:04 pm
Posts: 260

Code:

   <class entity-name="Parent" table="Parent"> 
        <id name="parentId" type="int"> 
        </id> 
        <set name="Children" lazy="true" inverse="true" cascade="all-delete-orphan"> 
            <key column="parentId"/> 
            <one-to-many class="Child" /> 
        </set> 
    </class> 

    <class entity-name="Child" table="Child"> 
        <composite-id> 
            <key-property name="parentId" type="int"/> 
            <key-property name="childNumber" type="int"/> 
        </composite-id> 
        <many-to-one name="Parent" entity-name="Parent" column="parentId" update="false" insert="false"/> 
    </class> 

I just removed not-null="true" on the <set>

Top

mschulz

Post subject:

Posted: Wed May 17, 2006 1:20 pm

Beginner

Joined: Sat Jan 31, 2004 7:19 pm
Posts: 39

Maybe I'm wrong in the above and should not insist on a full mapping for
both tables. I should also be able to get away with a composite, like:

Code:

<!-- ParentChild, Variant 3a -->

   <class entity-name="Parent" table="Parent">
        <id name="parentId" type="int">
        </id>
        <set name="Child" inverse="true" cascade="all-delete-orphan">
            <key column="parentId" not-null="true" />
            <composite-element class="Child">
                <property name="childNumber" type="int"/>
            </composite-element>
        </set>
    </class>

Oops:

Code:

TestParentChild  - Error: 
java.lang.NullPointerException
   at org.dom4j.tree.AbstractElement.addElement(AbstractElement.java:825)
   at org.hibernate.collection.PersistentElementHolder.readFrom(PersistentElementHolder.java:104)
   at org.hibernate.loader.Loader.readCollectionElement(Loader.java:994)
   at org.hibernate.loader.Loader.readCollectionElements(Loader.java:635)
   at org.hibernate.loader.Loader.getRowFromResultSet(Loader.java:580)
   at org.hibernate.loader.Loader.doQuery(Loader.java:689)
   at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
   at org.hibernate.loader.Loader.loadCollection(Loader.java:1923)
   at org.hibernate.loader.collection.CollectionLoader.initialize(CollectionLoader.java:71)
   at org.hibernate.persister.collection.AbstractCollectionPersister.initialize(AbstractCollectionPersister.java:520)
   at org.hibernate.event.def.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeCollectionEventListener.java:60)
   at org.hibernate.impl.SessionImpl.initializeCollection(SessionImpl.java:1695)
   at org.hibernate.type.CollectionType.getCollection(CollectionType.java:501)
   at org.hibernate.type.CollectionType.resolveKey(CollectionType.java:335)
   at org.hibernate.type.CollectionType.resolve(CollectionType.java:329)
   at org.hibernate.engine.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:113)
   at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:842)
   at org.hibernate.loader.Loader.doQuery(Loader.java:717)
   at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
   at org.hibernate.loader.Loader.doList(Loader.java:2149)
   at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2033)
   at org.hibernate.loader.Loader.list(Loader.java:2028)
   at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:375)
   at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:308)
   at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:153)
   at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1129)
   at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79)

I would have expected that the node names would be defaulted to
the appropriate name/class values, but that can be fixed:

Code:

<!-- ParentChild, Variant 3b -->

   <class entity-name="Parent" table="Parent">
        <id name="parentId" type="int">
        </id>
        <set name="Child" node="." inverse="true" cascade="all-delete-orphan">
            <key column="parentId" not-null="true" />
            <composite-element class="Child" node="Child">
                <property name="childNumber" type="int"/>
            </composite-element>
        </set>
    </class>

Notice the requird node attribute in composite-element, as well
as the leveled hierarchy by adding a node="." attribute to the set.
That gives me:

Code:

<?xml version="1.0" encoding="UTF-8"?>

  <Parents>
    <Parent>
      <parentId>1</parentId>
      <Child>
        <childNumber>11</childNumber>
      </Child>
      <Child>
        <childNumber>12</childNumber>
      </Child>
    </Parent>
    <Parent>
      <parentId>2</parentId>
      <Child>
        <childNumber>21</childNumber>
      </Child>
      <Child>
        <childNumber>22</childNumber>
      </Child>
    </Parent>
  </Parents>

Wait a second, where's the parentId in the Child elements?
Let's try this:

Code:

<!-- ParentChild, Variant 3c -->

   <class entity-name="Parent" table="Parent">
        <id name="parentId" type="int">
        </id>
        <set name="Children" inverse="true" node="." cascade="all-delete-orphan">
            <key column="parentId" not-null="true" />
            <composite-element class="Child" node="Child">
                <property name="parentId" type="int"/>
                <property name="childNumber" type="int"/>
            </composite-element>
        </set>

    </class>

For which I get the well-deserved punishment as follows:
[code]
Hibernate [odr_Hibernate] ERROR: org.hibernate.MappingException: Repeated column in mapping for collection: Parent.Children column: parentId
org.hibernate.MappingException: Repeated column in mapping for collection: Parent.Children column: parentId
at org.hibernate.mapping.Collection.checkColumnDuplication(Collection.java:290)
at org.hibernate.mapping.Collection.checkColumnDuplication(Collection.java:313)
at org.hibernate.mapping.Collection.validate(Collection.java:270)
at org.hibernate.mapping.Set.validate(Set.java:19)
at org.hibernate.cfg.Configuration.validate(Configuration.java:988)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1169)
[code/]

This gets us back to the initial question, why oh why is this checked?
It looks like here the parent implies and enforces the parentId property, and I have nothing against managing that automagically, but the Child
class or in the case of a dynamic object, the XML element should
be able to simply reflect and/or duplicate that information, without Hibernate getting too excited about it.

So for the time being, the winner is Variant 3c, which at least allows
to split out some XML.

In the next episode:
Persistence of the XML we managed to get out of all this.

Top

mschulz

Post subject:

Posted: Wed May 17, 2006 1:55 pm

Beginner

Joined: Sat Jan 31, 2004 7:19 pm
Posts: 39

Trying use variant 3b of the mapping file and persisting a single Parent:

Code:

logger.debug("Parent: " + el.elementText("parentId"));
Session session = sess.getSession(EntityMode.DOM4J);                 session.update(el);
sess.close();

I get:

Code:

TestParentChild  - Parent: 2
TestParentChild  - Exception: 
java.lang.ClassCastException: org.hibernate.type.ComponentType
   at org.hibernate.engine.Cascade.cascadeCollectionElements(Cascade.java:277)
   at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java:185)
   at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:160)
   at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:108)
   at org.hibernate.engine.Cascade.cascade(Cascade.java:248)
   at org.hibernate.engine.Cascade.cascade(Cascade.java:223)
   at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.cascadeOnUpdate(DefaultSaveOrUpdateEventListener.java:331)
   at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.performUpdate(DefaultSaveOrUpdateEventListener.java:303)
   at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.entityIsDetached(DefaultSaveOrUpdateEventListener.java:216)
   at org.hibernate.event.def.DefaultUpdateEventListener.performSaveOrUpdate(DefaultUpdateEventListener.java:33)
   at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:70)
   at org.hibernate.impl.SessionImpl.fireUpdate(SessionImpl.java:588)
   at org.hibernate.impl.SessionImpl.update(SessionImpl.java:576)
   at org.hibernate.impl.SessionImpl.update(SessionImpl.java:568)

Well, I'm not sure what that means, except that I'm stuck again.

Q4: Is this supposed to work? Is is experimental?
Is it easy to fix?

Top

mschulz

Post subject:

Posted: Wed May 17, 2006 2:16 pm

Beginner

Joined: Sat Jan 31, 2004 7:19 pm
Posts: 39

And here's sequel #1, thanks to bkmr_77's reply:

Let's try the following mapping, after removing the not-null attribute:

Code:

<!-- ParentChild, Variant 1b -->

   <class entity-name="Parent" table="Parent">
        <id name="parentId" type="int">
        </id>
        <set name="Children" node="." cascade="all-delete-orphan">
            <key column="parentId"/>
            <one-to-many class="Child" />
        </set>
    </class>

    <class entity-name="Child" table="Child">
        <composite-id>
            <key-property name="parentId" type="int"/>
            <key-property name="childNumber" type="int"/>
        </composite-id>
    </class>

Indeed, I get:

Code:

<?xml version="1.0" encoding="UTF-8"?>

  <Parents>
    <Parent>
      <parentId>1</parentId>
      <Child>
        <parentId>1</parentId>
        <childNumber>11</childNumber>
      </Child>
      <Child>
        <parentId>1</parentId>
        <childNumber>12</childNumber>
      </Child>
    </Parent>
    <Parent>
      <parentId>2</parentId>
      <Child>
        <parentId>2</parentId>
        <childNumber>21</childNumber>
      </Child>
      <Child>
        <parentId>2</parentId>
        <childNumber>22</childNumber>
      </Child>
    </Parent>
  </Parents>

And, by the way, we suddenly don't have a problem any more with
the parentId element in the Child elements. So far so good.

What happens if I want to persist the above:

Code:

Exception: 
org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch update
   at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:91)
   at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:79)
   at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
   at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:202)
   at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:230)
   at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:142)
   at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:296)
   at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
   at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1009)
   at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:361)
   at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:106)
Caused by: com.sybase.jdbc3.jdbc.SybBatchUpdateException: JZ0BE: BatchUpdateException: Error occurred while executing batch statement: The column parentId in table Child does not allow null values.

   at com.sybase.jdbc3.jdbc.ErrorMessage.raiseBatchUpdateException(Unknown Source)
   at com.sybase.jdbc3.jdbc.SybStatement.batchLoop(Unknown Source)
   at com.sybase.jdbc3.jdbc.SybStatement.sendBatch(Unknown Source)
   at com.sybase.jdbc3.jdbc.SybStatement.executeBatch(Unknown Source)
   at com.sybase.jdbc3.jdbc.SybStatement.executeBatch(Unknown Source)
   at com.sybase.jdbc3.jdbc.SybPreparedStatement.executeBatch(Unknown Source)
   at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:58)
   at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:195)
   ... 10 more

That of course is because the 'not-null' property tells Hibernate not to
just move the disassociated records out of the way.

A quick search through the documentation and forum will tell you as much.

Which of course begs the question which use case is _really_ supported
here. It looks like Hibernate still want's to manage the foreign keys in
the Child table, even though the facts speak against that:
1) the FK field is part of the PK and thus not nullable, which is
easy enough to determine from the DB and/or the mapping.
2) the cascade attribute should be a good hint too that the parent
should manage all the children.

Q5: Why does this not work despite the use case being so obvious
and easy to deal with?

[ To tell the truth, this is a fundamental question, which has been
asked many times on the forum, but every single one has been
told off by one or the other developer running out of patience. ]

Top

mschulz

Post subject:

Posted: Wed May 17, 2006 2:22 pm

Beginner

Joined: Sat Jan 31, 2004 7:19 pm
Posts: 39

To summarize, I still don't have a solution for what I'm trying to do
with Hibernate.

There are up to 5 enhancements/bugs in here and
I would like to get an assessment which of them would be easy to tackle.

Also, if someone knows whether any or all of these are already
in the bug database I can certainly hold back duplicating those.

I you've managed to read through all of this, thanks for your patience.

Martin

Top

mschulz

Post subject:

Posted: Thu May 18, 2006 9:26 am

Beginner

Joined: Sat Jan 31, 2004 7:19 pm
Posts: 39

I would maintain that Variant 1 is valid.

According to the reference manual, 10.11. Transitive persistence:

Recommendation:
...
If the child object's lifespan is bounded by the lifespan of the of the parent object make it a lifecycle object by specifying cascade="all,delete-orphan".

That's what I'm doing and that's what isn't working.

Top

mschulz

Post subject:

Posted: Thu May 18, 2006 10:37 am

Beginner

Joined: Sat Jan 31, 2004 7:19 pm
Posts: 39

Note that despite the cascade attribute, in variant 1b, Hibernate tries
to manage the collection as references by manipulating the foreign keys.

Witness the use of update statements to 'delete from the collection'
(one would expect a delete statement, as the child is lifecycle managed),
and the use of update statements to 'insert into the collection'
(one would expect a plain insert statement to be used).

From the debug log:

Code:

[main] DEBUG org.hibernate.persister.collection.AbstractCollectionPersister  - done deleting collection
[main] DEBUG org.hibernate.persister.collection.AbstractCollectionPersister  - Deleting collection: [Parent.Children#1]
[main] DEBUG org.hibernate.jdbc.AbstractBatcher  - reusing prepared statement
[main] DEBUG org.hibernate.SQL  - update Child set parentId=null where parentId=?

Note the terminology: delete -> transmuted to an update statement.
[ and similarly, insert -> transmuted to an update statement, not shown ]
And of course we can't just say not-null on the key, as that fails in
its own right as per variant 1.

Wether we cascade="all" or cascade="none", Hibernate will manage the
set using update statements (which all fail in this scenario).

Q6: Why is there no configuration on collections to leave them alone,
ie. declare them, load them according to the lazy attribute, but never
persist them, reference or value semantics.
That would be clearly still good enough for me, as I can at least manage
the export side of things without writing any code.

Let's try something different now (Variant 1c):
Adding delete-all and insert SQL statements to the mapping:

Code:

<!-- ParentChild, Variant 1c -->

   <class entity-name="Parent" table="Parent">
        <id name="parentId" type="int">
        </id>
        <set name="Children" node="." cascade="all-delete-orphan">
            <key column="parentId" not-null="true"/>
            <one-to-many class="Child"/>
            <sql-insert>
                insert into Child values (?, ?)
            </sql-insert>
            <sql-delete-all>
                delete from Child where parentId = ?
            </sql-delete-all>
        </set>
    </class>

    <class entity-name="Child" table="Child">
        <composite-id>
            <key-property name="parentId" type="int"/>
            <key-property name="childNumber" type="int"/>
        </composite-id>
    </class>

Indeed the delete passes, but shock, the insert:

Code:

3140 [main] DEBUG org.hibernate.SQL  - delete from Child where parentId = ?
3140 [main] DEBUG org.hibernate.type.IntegerType  - binding '1' to parameter: 1
3140 [main] DEBUG org.hibernate.jdbc.AbstractBatcher  - Adding to batch
3140 [main] DEBUG org.hibernate.persister.collection.AbstractCollectionPersister  - done deleting collection
...
3140 [main] DEBUG org.hibernate.persister.collection.AbstractCollectionPersister  - Inserting collection: [Parent.Children#2]
3140 [main] DEBUG org.hibernate.SQL  - insert into Child values (?, ?)
3140 [main] DEBUG org.hibernate.jdbc.AbstractBatcher  - preparing statement
3140 [main] DEBUG org.hibernate.type.IntegerType  - binding '2' to parameter: 1
3156 [main] DEBUG org.hibernate.type.IntegerType  - binding '2' to parameter: 2
3156 [main] DEBUG org.hibernate.type.IntegerType  - binding '21' to parameter: 3
...
3219 [main] DEBUG org.hibernate.util.JDBCExceptionReporter  - could not insert collection: [Parent.Children#2] [insert into Child values (?, ?)]
java.sql.SQLException: JZ0SB: Parameter index out of range: 3.
   at com.sybase.jdbc3.jdbc.ErrorMessage.raiseError(Unknown Source)
   at com.sybase.jdbc3.jdbc.ParamManager.for(Unknown Source)
   at com.sybase.jdbc3.jdbc.ParamManager.doSetParam(Unknown Source)
   at com.sybase.jdbc3.jdbc.ParamManager.setParam(Unknown Source)
   at com.sybase.jdbc3.jdbc.SybPreparedStatement.a(Unknown Source)
   at com.sybase.jdbc3.jdbc.SybPreparedStatement.a(Unknown Source)
   at com.sybase.jdbc3.jdbc.SybPreparedStatement.setInt(Unknown Source)
   at org.hibernate.type.IntegerType.set(IntegerType.java:41)
   at org.hibernate.type.NullableType.nullSafeSet(NullableType.java:85)
   at org.hibernate.type.NullableType.nullSafeSet(NullableType.java:63)
   at org.hibernate.type.ComponentType.nullSafeSet(ComponentType.java:261)
   at org.hibernate.type.ManyToOneType.nullSafeSet(ManyToOneType.java:71)
   at org.hibernate.persister.collection.AbstractCollectionPersister.writeElement(AbstractCollectionPersister.java:697)
   at org.hibernate.persister.collection.AbstractCollectionPersister.recreate(AbstractCollectionPersister.java:1037)
   at org.hibernate.action.CollectionRecreateAction.execute(CollectionRecreateAction.java:26)
   at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:243)
   at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:227)
   at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:144)
   at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:296)
   at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
   at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1009)
   at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:361)
   at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:106)

So I specify an insert statement, the AbstractCollectionPersister says
it's inserting, we have a life-cycle object we manage from the Parent,
but somehow Hibernate still insists of using the three parameters corresponding to the update statement?

Not only is the life-cycle management broken here, but to add insult
to injury, we cannot turn it off and just use the loading part.

Top

mschulz

Post subject:

Posted: Fri May 26, 2006 9:28 am

Beginner

Joined: Sat Jan 31, 2004 7:19 pm
Posts: 39

See JIRA HHH-1788 for a bug and patch to get variant 1 working.
Vote for it.

Top

mschulz

Post subject:

Posted: Fri May 26, 2006 9:32 am

Beginner

Joined: Sat Jan 31, 2004 7:19 pm
Posts: 39

Also note that cascade delete-orphans does not work with dynamic
modes.

See HHH-1784 and vote for it.

Top

mschulz

Post subject:

Posted: Tue Jun 13, 2006 1:51 pm

Beginner

Joined: Sat Jan 31, 2004 7:19 pm
Posts: 39

For scenarios 2a/2b, with the attempt to bi-di map
the parent and child, see Jira issues:
- HHH 446 [ embed-xml in key-many-to-one ]
- HHH 796 [ embed-xml causing NPE ]

Please vote for these issues!

Top

Page 1 of 1

[ 12 posts ]

Board index » Hibernate & Java Persistence » Hibernate Users

All times are UTC - 5 hours [ DST ]

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum