From: Chris Hyzer
Sent: Monday, January 19, 2009 4:31 PM
Subject: RE: referential integrity of membership owners
I coded this in the grouper API,
and the changes that are required to the API are:
Membership.setOwnerUuid(), you now need to call Membership.setOwnerGroupId (or
stem id). Same for getter if we don’t want to keep the old method
The queries in
MembershipDAO that use owner, now either pass in groupId or stemId, not a
generic owner id.
So… is this ok for an API
change? Anyone (not in core grouper team) who is using membership owners
somewhere who will be inconvenienced by this? I might be able to add some
methods back in to deprecate…
While we are at it, the membership
“via” column, which is the composite uuid if a composite membership, or a group
uuid if an effective membership can be split out and we can add foreign keys on
the two cols. Sound good? Can we discuss all of this on wed?
From: Chris Hyzer
Sent: Friday, January 02, 2009 5:25 PM
Subject: referential integrity of membership owners
Im thinking more about the grouper registry data design and
improvements we can make for 1.5. In the grouper_memberships table, there
is an owner_id col, which points to the group id or stem id that the membership
involves. It is impossible to put a foreign key on this col since it
points to two different tables.
I bet we could relatively easily change the data model (and
perhaps not the java object model), so that instead of owner_id, there is
owner_group_id and owner_stem_id which would be mutually exclusive. Then
we could put foreign keys on those columns so we know the uuid’s are
valid. Another advantage is when using the data model (e.g. for triggers
or views or whatever), it isn’t easy to tell if a membership record involves a
group or stem, it requires a lookup in another table (either field table, or
groups or stems).
Any thoughts on this?