problem with simple relationship in 1.2B1

From: Bryan Lewis (brya..aine.rr.com)
Date: Mon Apr 17 2006 - 14:04:10 EDT

  • Next message: Mike Kienenberger: "Attempting to implement a "MATCH ALL VALUES" expression at the application level."

    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.

    This archive was generated by hypermail 2.0.0 : Mon Apr 17 2006 - 14:04:36 EDT