createPermId in DataContext

From: Craig Miskell (
Date: Thu Nov 14 2002 - 20:29:45 EST

  • Next message: Andrus: "Re: Flattened relationship support"

    Hi again,
            Are you sick of me yet?

    We have a situation that I'd like to describe, and then propose a
    solution for (requires mods to Cayenne). Hopefully by explaining why,
    you won't think me completely mad :)

    We are implementing an automatic audit trail system, where we have our
    own subclass of DataContext that overrides commitChanges. Before it
    calls the super implementation of commitChanges, it checks for inserted,
    updated and deleted objects, and creates audit records (also db objects
    in the same context) for the changes. This in theory works well - the
    audit logs get committed at the same time as the actual changes, or else
    everything is rolled back. Plus, all programmatic changes are 99.9999%
    likely to come through commitChanges rather than raw SQL. We can also
    then programmatically control auditing (what tables, when, what level

    Now the problem. For all audit records, we need to know the PK of the
    row being audited. However, for "inserted" objects, a PK will not be
    generated until commitChanges is called. DataContext exposes
    createPermId as public API, and this is what is used internally.
    However, it assumes that the object passed still has a TempObjectId
    (casts getObjectId to that class, plus other stuff). And commitChanges
    on DataContext assumes that all inserted objects need to create a
    permId, so calls createPermIds (which calls createPermId)

    Proposal: Modify createPermId to first check if the object has a
    TempObjectId or not. If it's temporary, proceed. If not, assume it's
    all ok and return immediately

    How does this help:
    1) It means we can call createPermId at an appropriate time (while
    generating audit records).
    2) It means that createPermId will become a more robust public API (can
    be called with any DataObject and will gracefully handle an object with
    an id already). Others may have other times when it is necessary to
    force the creation of a primary key.

    There may be bits of cayenne that assume that if an Object has a
    Permanent ID that it has been committed to the database. This might
    limit the usefulness of createPermId as public api, in which case
    perhaps it should be made at least protected (still useable in our
    particular case above, and indeed encourages only using it in a
    controlled and limited environment)

    What do you all think?


    This archive was generated by hypermail 2.0.0 : Thu Nov 14 2002 - 20:29:18 EST