Grouper Developers Forum

[Chris Hyzer <>]

This is all done for 1.5.

 

https://bugs.internet2.edu/jira/browse/GRP-212

 

The cols are expanded, and there are foreign keys on all four new cols.

https://wiki.internet2.edu/confluence/display/GrouperWG/Grouper+change+log+v1.5

the membership table cols owner_id and via_id were expanded to owner_group_id, owner_stem_id, via_group_id, and via_composite_id.

To upgrade:

    * Turn off grouper systems for updates
    * Backup the registry, e.g. with export: gsh -xmlexport GrouperSystem /whatever/20090127_1_5.xml
    * Either run the in-place upgrade, or reinstall the registry and import
    * [in-place] Run: grouper_home/bin/gsh -registry -check
          o Then look at the result script, and execute that script, perhaps with:
            grouper_home/bin/gsh -registry -runsqlfile C:/mchyzer/isc/dev/grouper_v1_4/grouper/ddlScripts/grouperDdl_20090120_08_39_44_148.sql
    * -or- [reinstall] grouper_home/bin/gsh -registry -drop -runscript
          o gsh -xmlimport GrouperSystem /whatever/20090127_1_5.xml

merge grouper.properties with grouper.example.properties, adding property: ddlutils.dropMembershipBackupColsFromOwnerViaUpgrade

Once the membership col upgrade is done, set this to true and run: grouper_home/bin/gsh -registry -deep (and run the resulting script, it will drop the cols grouper_memberships.owner_id_bak and grouper_memberships.via_id_bak

[ Show » ]

Chris Hyzer - [27/Jan/09 07:33 AM ] This is done. The cols are expanded, and there are foreign keys on all four new cols. https://wiki.internet2.edu/confluence/display/GrouperWG/Grouper+change+log+v1.5 the membership table cols owner_id and via_id were expanded to owner_group_id, owner_stem_id, via_group_id, and via_composite_id. To upgrade:     * Turn off grouper systems for updates     * Backup the registry, e.g. with export: gsh -xmlexport GrouperSystem /whatever/20090127_1_5.xml     * Either run the in-place upgrade, or reinstall the registry and import     * [in-place] Run: grouper_home/bin/gsh -registry -check           o Then look at the result script, and execute that script, perhaps with:             grouper_home/bin/gsh -registry -runsqlfile C:/mchyzer/isc/dev/grouper_v1_4/grouper/ddlScripts/grouperDdl_20090120_08_39_44_148.sql     * -or- [reinstall] grouper_home/bin/gsh -registry -drop -runscript           o gsh -xmlimport GrouperSystem /whatever/20090127_1_5.xml merge grouper.properties with grouper.example.properties, adding property: ddlutils.dropMembershipBackupColsFromOwnerViaUpgrade Once the membership col upgrade is done, set this to true and run: grouper_home/bin/gsh -registry -deep (and run the resulting script, it will drop the cols grouper_memberships.owner_id_bak and grouper_memberships.via_id_bak

 

 

From: Chris Hyzer
Sent: Monday, January 19, 2009 4:31 PM
To: ''
Subject: RE: referential integrity of membership owners

 

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