I understand the need to do consistent audit, but I am also concerned
about exposing all these details (I mean there is no such thing as
"flattened object"). The fact that DataContext was so tightly coupled
with the database layer prompted ObjectContext design ... exposing
flattened stuff would be a step back.
So maybe we can approach it from a different angle and come up with a
generic audit solution?
Logically if you are doing audit at the DB-level, you should be
analyzing DB data. I would think that intercepting BatchQueries and
attaching change log to a current transaction would make more sense.
Since M9 transactions are bound to threads, so we may change
DataContextCommitAction to avoid starting a new transaction if one is
already bound to the thread. This way a two-phase commit will be
possible within the same JDBC transaction.
The question remains how to intercept the queries. Maybe add a new
method to DataContextDelegate (or maybe redefine "willPerformSelect"
to "willPerformQuery").
Does it make sense?
Andrus
On Dec 22, 2005, at 2:33 AM, Mike Kienenberger wrote:
> Yeah, our requirement is to do them both at once. We don't care
> about failures since our log is used to answer questions about how the
> data got to a specific state rather than what operations were
> attempted.
>
> On 12/21/05, Cris Daniluk <cris.danilu..mail.com> wrote:
>> On 12/21/05, Mike Kienenberger <mkienen..mail.com> wrote:
>>> On 12/20/05, Cris Daniluk <cris.danilu..mail.com> wrote:
>>>> Seems nice, though it does expose a many more methods on what is
>>>> already a fairly exposed API.
>>>
>>> True, but if it's useful to get newObjects, modifiedObjects, and
>>> deletedObjects, it should be equally useful to get flattenedObjects
>>> (it's certainly useful to me).
>>
>> I think I agree. Just figured I'd mention it :)
>>
>>
>>> I was wondering the same thing myself after I sent the message. I
>>> think the majority of my auditing code has to run before
>>> commitChanges
>>> (since it creates a bunch of new ChangeLog records). However, it's
>>> probably possible to update the contents of those records.
>>>
>>
>> Ahh. We actually do our auditing in a separate transaction, so that a
>> failure in audit will not correspond to a failure in the original
>> transaction. Plus, the failure of a transaction is still a
>> transaction
>> that is audited for us, so that's another thing that precludes
>> auditing in the transaction (if the audit write fails, we log it to
>> manually update the audit tables later).
>>
>> I could see where you'd need it in the same transaction, though -
>> particularly in applications where the audit record is as
>> important as
>> the record itself. I've wanted pre-transaction-commit and
>> pre-cayenne-commit operations in Cayenne for a while now. A
>> pre-transaction commit would probably work because the sequences have
>> already been resolved and its no longer a temp ObjectID. Not sure how
>> difficult that would be though... haven't had the time to really dig
>> into it.
>>
>> Cris
This archive was generated by hypermail 2.0.0 : Fri Dec 30 2005 - 12:09:11 EST