Bryan,
nothing comes to mind right away. Could you possibly create a Jira
issue with a DataMap that contains the entities involved - I'll run
it in debugger and see what's going on.
Andrus
On Apr 17, 2006, at 10:04 PM, Bryan Lewis wrote:
I'm getting a Commit Exception that I can't figure out. It happens in
commitChanges() with a single new object. When I log the inserted
object
I get the expected:
{<ObjectId:BRADTask, TEMP:000001F6214E0102>; new
[...
creationDate=>2006-04-17 13:46:32.375
author=>{<ObjectId:BRADUserInfo, USERNAME=blewis>}
application=>{<ObjectId:BRADApplication, OID=185>}]}
Note that the last line shows a non-null "application" relationship.
However, the key for it is missing in the SQL:
[QueryLogger] INSERT INTO BRADTask (APPLICATION_ID, AUTHOR_ID,
CREATIONDATE, ... )
VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)
[QueryLogger] [batch bind: NULL, NULL, '2006-04-17
10:27:08.687', ... ]
[QueryLogger] *** error.java.sql.SQLException: ORA-01400: cannot
insert
NULL into ("...."BRADTASK"."APPLICATION_ID")
I see nothing unusual about the definition of the relationship in the
modeler.
<db-entity name="BRADTASK">
<db-attribute name="APPLICATION_ID" type="INTEGER"
isMandatory="true"/>
...
<db-relationship name="application" source="BRADTASK"
target="BRADAPPLICATION" toMany="false">
<db-attribute-pair source="APPLICATION_ID" target="OID"/>
</db-relationship>
This didn't occur on version 1.2M10; it began with B1 and continues
with
B2. I've reproduced it on Oracle 8 and PostgreSQL, in case it was
another Oracle-only weirdness but it isn't.
Stack trace with 1.2B2 on Postgres:
org.postgresql.util.PSQLException: ERROR: null value in column
"application_id" violates not-null constraint
at
org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse
(QueryExecutorImpl.java:1501)
at
org.postgresql.core.v3.QueryExecutorImpl.processResults
(QueryExecutorImpl.java:1286)
at
org.postgresql.core.v3.QueryExecutorImpl.execute
(QueryExecutorImpl.java:336)
at
org.postgresql.jdbc2.AbstractJdbc2Statement.executeBatch
(AbstractJdbc2Statement.java:2540)
at
org.objectstyle.cayenne.access.jdbc.BatchAction.runAsBatch
(BatchAction.java:164)
at
org.objectstyle.cayenne.access.jdbc.BatchAction.performAction
(BatchAction.java:114)
at
org.objectstyle.cayenne.access.DataNodeQueryAction.runQuery
(DataNodeQueryAction.java:95)
at
org.objectstyle.cayenne.access.DataNode.performQueries
(DataNode.java:309)
at
org.objectstyle.cayenne.access.DataDomainFlushAction.runQueries
(DataDomainFlushAction.java:255)
at
org.objectstyle.cayenne.access.DataDomainFlushAction.flush
(DataDomainFlushAction.java:177)
at
org.objectstyle.cayenne.access.DataDomain.onSyncFlush
(DataDomain.java:827)
at
org.objectstyle.cayenne.access.DataDomain$2.transform
(DataDomain.java:798)
at
org.objectstyle.cayenne.access.DataDomain.runInTransaction
(DataDomain.java:853)
at org.objectstyle.cayenne.access.DataDomain.onSync
(DataDomain.java:795)
at
org.objectstyle.cayenne.access.DataContext.flushToParent
(DataContext.java:1217)
at
org.objectstyle.cayenne.access.DataContext.commitChanges
(DataContext.java:1121)
On Oracle the trace is the same, until it gets down to the jdbc level,
of course.
