grouper-dev - Re: [grouper-dev] changelog implementation sketch
Subject: Grouper Developers Forum
List archive
- From: "GW Brown, Information Systems and Computing" <>
- To: Tom Zeller <>, Grouper Dev <>
- Subject: Re: [grouper-dev] changelog implementation sketch
- Date: Tue, 10 Jun 2008 16:12:09 +0100
--On 10 June 2008 09:17 -0500 Tom Zeller
<>
wrote:
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?
This is already a rather long thread, and I'm loathe to add more to it,
but...
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.
One row per membership change wouldn't be down to the LDIF format - it would mean we are not storing enough metadata in the database table. I hadn't thought about looking from the member perspective. In principle we should be able to do this, but one row per membership change doesn't strike me as scalable. 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.
Group-centrically :
dn: name=stem:group,uuid=...
add: members
members: subject...
Member-centrically ?
dn: name=subject
add: groups
groups: stem:group
Doesn't seem right to me. I imagine we would want to be able to easily
query for changes affecting a member, and consequently it seems we would
probably want to add the member (or it's subject id) as a column, and
hence we would want one row per membership change...which makes me think
LDIF isn't the right way.
In the end it could come down to how often we need to ask questions of the change log. If infrequently we can live with slower response times.
Another approach would be to have an asynchronous process for expanding the 'batch' group membership changes into one row per change so that it does not slow down the API.
TomZ
----------------------
GW Brown, Information Systems and Computing
- Re: [grouper-dev] changelog implementation sketch, (continued)
- Re: [grouper-dev] changelog implementation sketch, GW Brown, Information Systems and Computing, 06/06/2008
- Re: [grouper-dev] changelog implementation sketch, Tom Zeller, 06/06/2008
- 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.