grouper-dev - Re: [grouper-dev] changelog implementation sketch
Subject: Grouper Developers Forum
List archive
- From: Tom Barton <>
- To: Tom Zeller <>
- Cc: "GW Brown, Information Systems and Computing" <>, Grouper Dev <>
- Subject: Re: [grouper-dev] changelog implementation sketch
- Date: Tue, 10 Jun 2008 21:50:18 -0500
For audit, the first order of business is to preserve the information, and for that purpose (alone) we don't need to store the info in both a group-centric and a member-centric way.
Actually answering point-in-time questions should be of rather low frequency compared to using the info for incremental change notification, and it's only the latter that has a need for low latency.
So I think we can pick the single representation (group-centric or member-centric) best suited to sensibly representing changes. And since not all changes to group info are membership related, it looks like group-centric is the only single one that meets the need.
Tom
Tom Zeller wrote:
On Tue, Jun 10, 2008 at 10:12 AM, GW Brown, wrote:
--On 10 June 2008 09:17 -0500 Tom Zeller
<
<mailto:>>
wrote:
Representing changes from a group-centric point of view via LDIF
seems
straightforward, but what about member-centrically ? e.g. how
someone's
group memberships have changed.
What is the context here? Are we back to the subject id changing or
is this to make it easier to query from a member point of view i.e.
show me all the memberships for 'x' on a given date?
The latter, make it easier/possible to query changes from a member point of view.
If the actual change definitions - the LDIF or whatever format
we use - for a group can be queried using 'like' we could have
an inefficient means of finding relevant changes which would
allow us to compute a subject's memberships at a given point in
time.
I agree: querying LDIF via SQL seems inefficient, perhaps even improper.
begin:vcard fn:Tom Barton n:Barton;Tom org:University of Chicago;Networking Services & Information Technology adr;dom:1155 E. 60th St.;;Rm 309, 1155 Bldg;Chicago;IL;60637 email;internet: title:Sr. Director - Integration tel;work:+1 773 834 1700 version:2.1 end:vcard
- Re: [grouper-dev] changelog implementation sketch, (continued)
- Re: [grouper-dev] changelog implementation sketch, Tom Barton, 06/06/2008
- Re: [grouper-dev] changelog implementation sketch, GW Brown, Information Systems and Computing, 06/06/2008
- Re: [grouper-dev] changelog implementation sketch, Tom Barton, 06/06/2008
- RE: [grouper-dev] changelog implementation sketch, Chris Hyzer, 06/06/2008
- Re: [grouper-dev] changelog implementation sketch, Tom Barton, 06/06/2008
- Re: [grouper-dev] changelog implementation sketch, Tom Zeller, 06/06/2008
- RE: [grouper-dev] changelog implementation sketch, Chris Hyzer, 06/06/2008
- Re: [grouper-dev] changelog implementation sketch, Tom Zeller, 06/10/2008
- Re: [grouper-dev] changelog implementation sketch, GW Brown, Information Systems and Computing, 06/10/2008
- Re: [grouper-dev] changelog implementation sketch, Tom Zeller, 06/10/2008
- Re: [grouper-dev] changelog implementation sketch, Tom Barton, 06/10/2008
- RE: [grouper-dev] changelog implementation sketch, Chris Hyzer, 06/11/2008
- RE: [grouper-dev] changelog implementation sketch, GW Brown, Information Systems and Computing, 06/11/2008
- Re: [grouper-dev] changelog implementation sketch, Tom Zeller, 06/11/2008
- Re: [grouper-dev] changelog implementation sketch, GW Brown, Information Systems and Computing, 06/12/2008
- Re: [grouper-dev] changelog implementation sketch, Kathryn Huxtable, 06/12/2008
Archive powered by MHonArc 2.6.16.