Issue Details (XML | Word | Printable)

Key: NUCRDBMS-520
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Unassigned
Reporter: Guido Anzuoni
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
DataNucleus Store RDBMS

Exception removing elements in a one-to-many relationship with join table with element as a base class

Created: 11/Apr/11 01:28 PM   Updated: 09/May/11 09:59 AM   Resolved: 14/Apr/11 05:06 PM
Component/s: None
Affects Version/s: None
Fix Version/s: 3.0.0.m4

File Attachments: 1. Zip Archive jira520.zip (4 kB)



 Description  « Hide
The exception is:
com.mysql.jdbc.JDBC4PreparedStatement@127f79d: DELETE FROM `PCLASS_SAMPLES` USING `ACLASS` WHERE `PCLASS_SAMPLES`.`P_OID` = 10 AND `PCLASS_SAMPLES`.`A_OID` = 36 AND `ACLASS`.`TYPENAME` = ** NOT SPECIFIED **
13:27:51,406 (main) DEBUG [DataNucleus.Datastore.Retrieve] - Closing PreparedStatement org.datanucleus.store.rdbms.ParamLoggingPreparedStatement@f19d6e
13:27:51,406 (main) ERROR [DataNucleus.Datastore] - Remove request failed : SQLException
java.sql.SQLException: No value specified for parameter 3
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1055)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:926)
at com.mysql.jdbc.PreparedStatement.checkAllParametersSet(PreparedStatement.java:2522)
at com.mysql.jdbc.PreparedStatement.fillSendPacket(PreparedStatement.java:2498)
at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2345)
at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2289)
at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2274)
at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105)
at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105)
at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105)
at org.datanucleus.store.rdbms.ParamLoggingPreparedStatement.executeUpdate(ParamLoggingPreparedStatement.java:399)
at org.datanucleus.store.rdbms.SQLController.executeStatementUpdate(SQLController.java:407)
at org.datanucleus.store.rdbms.scostore.RDBMSAbstractCollectionStoreSpecialization.internalRemove(RDBMSAbstractCollectionStoreSpecialization.java:408)



Guido Anzuoni added a comment - 11/Apr/11 01:53 PM
The test case contains also the evidence that the relation is not persisted when
the owner is created in the same transaction where the relation is populated

Guido Anzuoni made changes - 11/Apr/11 01:53 PM
Field Original Value New Value
Attachment jira520.zip [ 11422 ]
Guido Anzuoni added a comment - 13/Apr/11 10:56 AM
Is there any suggestion for the fix or any workaround ?

Andy Jefferson added a comment - 14/Apr/11 09:22 AM
Why not look at the statement generation, and the method where that statement is used? I removed the discriminator a day ago but don't have time to download and run other tests.

And regarding "evidence the relation is not persisted", I suggest you read the JPA spec regarding cascade rules, and what the JPA scientist came up with. Cascade persist is not default; why would anyone want that ?

Guido Anzuoni added a comment - 14/Apr/11 11:20 AM - edited
About relation not persisted.
The 1-many is with the many side that are independent from the 1 side, i.e. the can live without the 1 side.
So cascade does not apply here.
A -> B, B are already persistent.
If A is persistent, A.getBCollection().add(B) the association table the binds B instances to A instances is populated the the FKs.
If A is persistent-new (even if flushed in the current EM) and B is persistent the above operation does not
ends with populating the association table with the FKs

For what concerns the removal of elements, the trunk solves the pb

Andy Jefferson added a comment - 14/Apr/11 05:06 PM
Assumed working

Andy Jefferson made changes - 14/Apr/11 05:06 PM
Status Open [ 1 ] Resolved [ 5 ]
Fix Version/s 3.0.0.m4 [ 11221 ]
Resolution Fixed [ 1 ]
Guido Anzuoni added a comment - 15/Apr/11 08:44 AM
Yes I confirm that the association table is now populated even in the same txn where the 1 side is persisted

Andy Jefferson made changes - 09/May/11 09:59 AM
Status Resolved [ 5 ] Closed [ 6 ]