You know... it may not be a bad idea to convert what you have created
into a patch that users can apply to Cayenne as needed. I've been
using qmail patches for years that increase access to its guts.
Obviously, having a slew of patches just to use Cayenne isn't a good
thing, but it wouldn't be difficult to update the patch file for every
major 1.2 release..
Cris
On 12/30/05, Mike Kienenberger <mkienen..mail.com> wrote:
> 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 - 16:40:06 EST