I don't quite understand what you're proposing. How would one get
the needed information out of a batch query? 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. Sounds
interesting, but I need something that works in the present, and it
sounds like this might require a lot of work before it's ready for
use.
What I'm doing now works. It isn't clean, but it works.
On 12/30/05, Andrus Adamchik <andru..bjectstyle.org> wrote:
> 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 - 15:27:13 EST