You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cayenne.apache.org by Bryan Lewis <br...@maine.rr.com> on 2006/04/17 20:04:10 UTC
problem with simple relationship in 1.2B1
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.
Re: problem with simple relationship in 1.2B1
Posted by Bryan Lewis <br...@maine.rr.com>.
As often happens, the effort of producing a test case found the bug on
our side. We have some low-level code that was clearing the dataContext
(rollbackChanges()) whenever a new page is invoked, and it was being
called between the create and the commit. I didn't see this at first,
being led astray by the fact that the commit used to work on the older
cayenne (weird, eh?) and the fact that the object looked correct when
it was printed to the log. Sorry about the false alarm.
Andrus Adamchik wrote:
> 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
>
>
Re: problem with simple relationship in 1.2B1
Posted by Andrus Adamchik <an...@objectstyle.org>.
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.
>
>