Grouper Developers Forum

[Chris Hyzer <>]

I coded this in the grouper API, and the changes that are required to the API are:

 

1.       If calling 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

2.       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?

 

Thanks!

Chris

 

From: Chris Hyzer
Sent: Friday, January 02, 2009 5:25 PM
To: ''
Subject: referential integrity of membership owners

 

Hey,

 

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?

 

Thanks,

Chris