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
etc.)
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.
Negatives:
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?
Craig
This archive was generated by hypermail 2.0.0 : Thu Nov 14 2002 - 20:29:18 EST