Grouper Developers Forum

[Tom Barton <>]

A basic question: is the contextId necessarily applied to all changes in 
a specific transaction? Ie, might it as well be thought of as a 
transactionId, identifying all actions that occur together in a logical 
and functional sense?

Should it label data, or should it label actions taken on the data, with 
current data values as arguments?

Chris Hyzer wrote:
> However, although I am not close to starting the PIT stuff, it is a
> bit of a thorn in my side as I think about how it will work.  I had
> my mind set on triggers, but deletes are a bit tricky...  When you
> delete a row, the contextId is not there, so how can the row and the
> contextId be inserted into the PIT table?  Three options:
>
> 1. Update the row with the new contextId, then delete it, and the
> trigger now knows the contextId 
> 2. Delete it, have the trigger insert
> into the PIT without the contextId, then use java to update the PIT
> with the known contextId (not exactly sure how to get the primary key
> of the PIT row) 
> 3. Just use Java and no triggers
> Its looking like the cleanest solution is now the third one... sorry
> to change course, but maybe we should start there, and if performance
> or other concerns warrant, we can try another one...  I kind of think
> since we are keeping the context id for deletes, #1 and #2 are a
> little kludgy...  I guess we could do a hybrid approach (updates with
> triggers and deletes with java), but that doesn't seem elegant
> either...  hmmm
>
> I wonder if the notification queue table needs contextId.  I have a
> feeling it does, so the same situation will occur.  The advantage to
> doing notifications from Java is we can filter what goes into the
> notification queue (and the cardinality), so the queue will be more
> accurate.  With triggers we will get a lot of noise in the queue (and
> singletons where need to go back and insert multiples), so the
> processing of the queue will require more work.
>
> Regards, Chris