grouper-dev - Re: [grouper-dev] Action Items: Grouper Call 4-Feb-09
Subject: Grouper Developers Forum
List archive
- From: Tom Barton <>
- To: Chris Hyzer <>
- Cc: Grouper Dev <>
- Subject: Re: [grouper-dev] Action Items: Grouper Call 4-Feb-09
- Date: Tue, 10 Feb 2009 08:50:33 -0600
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> 2. Delete it, have the trigger insert
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
into the PIT without the contextId, then use java to update the PIT> 3. Just use Java and no triggers
with the known contextId (not exactly sure how to get the primary key
of the PIT row)
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
- RE: [grouper-dev] Action Items: Grouper Call 4-Feb-09, (continued)
- RE: [grouper-dev] Action Items: Grouper Call 4-Feb-09, Chris Hyzer, 02/07/2009
- Re: [grouper-dev] Action Items: Grouper Call 4-Feb-09, Tom Barton, 02/07/2009
- RE: [grouper-dev] Action Items: Grouper Call 4-Feb-09, Chris Hyzer, 02/07/2009
- RE: [grouper-dev] Action Items: Grouper Call 4-Feb-09, Chris Hyzer, 02/07/2009
- Re: [grouper-dev] Action Items: Grouper Call 4-Feb-09, Tom Zeller, 02/07/2009
- RE: [grouper-dev] Action Items: Grouper Call 4-Feb-09, Chris Hyzer, 02/08/2009
- Re: [grouper-dev] Action Items: Grouper Call 4-Feb-09, Tom Barton, 02/07/2009
- Re: [grouper-dev] Action Items: Grouper Call 4-Feb-09, Tom Barton, 02/09/2009
- RE: [grouper-dev] Action Items: Grouper Call 4-Feb-09, Chris Hyzer, 02/09/2009
- Re: [grouper-dev] Action Items: Grouper Call 4-Feb-09, Tom Barton, 02/09/2009
- RE: [grouper-dev] Action Items: Grouper Call 4-Feb-09, Chris Hyzer, 02/09/2009
- Re: [grouper-dev] Action Items: Grouper Call 4-Feb-09, Tom Barton, 02/10/2009
- RE: [grouper-dev] Action Items: Grouper Call 4-Feb-09, Chris Hyzer, 02/10/2009
- RE: [grouper-dev] Action Items: Grouper Call 4-Feb-09, Chris Hyzer, 02/07/2009
Archive powered by MHonArc 2.6.16.