On 12/31/05, Andrus Adamchik <andru..bjectstyle.org> wrote:
> BatchQuery contain a matrix of values keyed by DbAttribute - this is
> what you need for audit, right? Still need to think how to handle
> deferred generated keys, but if we intercept the query at the right
> moment, they can be already there, solving your other problem as well.
>
> BatchQuery q;
> List dbAttributes = q.getDbAttributes();
> while(q.next()) {
> for(int i = 0; i < q.size(); i++) {
> DbAttribute a = (DbAttribute) dbAttributes.get(i);
> Object value = q.getValue(i);
>
> // append this data to the audit log
> // ...
>
> // note that in UPDATE batches attribute can be either
> // from 'UpdatedAttributes' or 'QualifierAttributes'
> }
> }
>
> // reset the batch so that Cayenne could process it again later
> q.reset();
Ok. The above makes sense and seems pretty simple.
> > And then add new objects to the commit? The process of adding
> > more inserts is
> > probably the two-stage commit that you're talking about.
>
> Yes. If possible you can simply append the audit log to your own
> InsertBatchQuery (maybe attaching it to the DataContext via
> "setUserProperty"). If not, you can create unregistered DataObjects
>, register them in
> DataContext after the first commit stage is done, and then commit again.
Call me dense, but I still don't see how to make a two-stage commit work.
Do I somehow abort the current commit and commit a second time,
somehow detecting that the auditing already occurred, and not doing
the auditing this second time? Or maybe detecting that changes were
made and "restarting" the commit process again, skipping the audit
changes the second time.
Perhaps a DataContextDelegate.willModifyQueriesAndReprocess() method
with true restarting the process and false continuing as normal.
Called right after pk values are generated and before actual
insert/update/delete statements run.
This could be how to control the flow, but I don't think I understand
enough to restart the commit.
> (you won't have any relationships in them, right?)
I currently have relationships from the audit record to the record
being audited as that's the only way I can have the primary key for
the record being audited assigned to my audit record for inserted
records. However, we can probably also fetch this information out of
the BatchQuery's DBAttribute with isPrimaryKey().
This archive was generated by hypermail 2.0.0 : Mon Jan 02 2006 - 11:54:53 EST