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 : Wed Dec 21 2005 - 18:33:19 EST