Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] move built in group attributes to the groups table

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] move built in group attributes to the groups table


Chronological Thread 
  • From: "GW Brown, Information Systems and Computing" <>
  • To: Chris Hyzer <>,
  • Subject: Re: [grouper-dev] move built in group attributes to the groups table
  • Date: Wed, 04 Mar 2009 09:30:32 +0000
Another issue:

The internal privilege model for what Access privilege is needed by a subject to read/write any particular attribute/field is modeled in grouper_fields e.g.

IS_NULLABLE NAME READ_PRIVILEGE TYPE WRITE_PRIVILEGE ------------------------------------ ------------------------------------
true description read attribute admin
false displayExtension view attribute admin
false extension view attribute admin

These are no longer in grouper_fields.

The UI makes a call: group.canWriteField(FieldFinder.find("extension"))
which now fails.

Gary

--On 04 March 2009 09:06 +0000 "GW Brown, Information Systems and Computing" <> wrote:

Chris,

I checked out HEAD the other day to start and fix some issues - and my
groups disappeared! - the name any way. The UI wraps groups with a Map
and assumes that group name, extension, display_name, display_extension,
description are attributes. I can 'fix' the UI code, but first wanted to
check that this was intentional - it might break other people's code as
well. We could, for example, allow read access through attributes but not
allow updates through setAttribute (I don't know if that used to work for
the naming attributes?)

Gary

--On 02 January 2009 15:19 -0500 Chris Hyzer
<>
wrote:

This is done for grouper 1.5 (probably due out this spring/summer).

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

############### SUMMARY ################
Now the group name, extension, display_name, display_extension,
description are all part of the grouper_groups table, and not in the
grouper_attributes table. This makes the data model more
straightforward, and easier to extend (see messages on the grouper-dev
list about adding triggers on group actions). Also, we should see a
slight performance gain, and have the ability to write more
straightforward queries.

############### TO UPGRADE ################
To upgrade, just do what any ddl upgrade needs:

- Export to xml, rebuild ddl with: grouper_home/bin/gsh -registry -drop,
then import xml

-or-

- Just upgrade in place. (export xml if prod for backup), then run:
grouper_home/bin/gsh -registry -check, and run that script per
instructions printed to stdout.

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

############### NOTES ################
DONE:
- fix views since they use old data model
- add ddl comments to new column names
- keep backup to attributes table to BAK_GROUPER_ATTRIBUTES
- drop bak_grouper_attributes if the property is set in
grouper.properties (and gsh -registry -deep is run):
ddlutils.dropAttributeBackupTableFromGroupUpgrade = false
- write the conversion and upgrade in grouperddl
- take grouper.setters.dont.cause.queries out of
grouper.example.properties - you can still query by attribute with
filters, e.g.
Set<Group> selectedGroups =
GrouperDAOFactory.getFactory().getGroup().findAllByAnyApproximateAttr("so
meGroupExtension"); - note that with this, these queries dont eagerly
fetch the attributes anymore (except name, displayName, etc)... I assume
this will speed things up, but let me know if I need to rethink - you can
still call group.getAttributeValue("name") etc
- remove fields from fields table
- write upgrade instructions
- advise that if using triggers or views that they need to be updated
- branch and upgrade UI and WS
- add some indexes on the new cols (e.g. unique on name, displayName,
parent/extension, parent/display_extension) - there is not configurable
attribute security (as you could have edited in the grouper_fields
table). The old defaults are the current security levels. - also,
attributes are not retrieved with groups (though the group columns are...
e.g. . This could have positive or negative performance implications
(depending on situation)

# before the group name etc was moved to the grouper_groups table, the
# attributes table was backed up. If it should not be backed up, or if
# the upgrade is done and works, then it can be removed, set to true, run:
# gsh -registry -deep
ddlutils.dropAttributeBackupTableFromGroupUpgrade = false;


Test on Oracle, Postgres, Mysql:

1. Install 1.4:
C:\mchyzer\isc\dev\grouper_v1_4\grouper\bin>gsh -registry -drop
-runscript C:\mchyzer\isc\dev\grouper_v1_4\grouper\bin>gsh -xmlimport
GrouperSystem ..\quickstart.xml

2. Look at groups in 1.4:
gsh
getGroups(":")

3. Get 1.5, and upgrade
C:\mchyzer\isc\dev\grouper-qs-1.2.0\grouper\bin>gsh -registry
-runscript

4. Look at groups in 1.5:
gsh
getGroups(":")



-----Original Message-----
From: Chris Hyzer
Sent: Thursday, December 11, 2008 12:31 AM
To:
''
Subject: RE: [grouper-dev] Grouper design call, Wednesday, 10 December
2008, 1200EST (1700Z)

Are there any objections to my starting work on this before the next
call in January? Not exactly sure I will have time, but just
curious... :) Of course this is not a must have, if it turns out to be
not as easy as I hope it is, we can table it.

Thanks,
Chris

> -----Original Message-----
> From: Chris Hyzer
> Sent: Tuesday, December 09, 2008 10:44 PM
> To:

> Subject: RE: [grouper-dev] Grouper design call, Wednesday, 10
December
> 2008, 1200EST (1700Z)
>
> Regarding 1.5 work items, the first thing I want to do is see if we
can
> move group name, extension, displayExtension, displayName,
description
> to the grouper_groups table like the grouper_stems table. I was
> discussing with Shilen, and he thought this was a good idea (correct
me
> if wrong).
>
> 1. When searching by group name, you are joining three tables
(groups,
> attributes, fields)
> 2. Hard to put a trigger on groups table (which name is affected?)
> 3. This is better db design... if it is a known field, and 1 to 1,
> should be a column...
> 4. Views etc would be more straightforward
> 5. Might speed up searches of groups by one of these cols or by
> attributes
>
> Anyways, if auditing, and notifications, etc builds on the DB, I
would
> like to get this in first...
>
> Any other DB changes we should consider (e.g. changing
> memberships.owner_id to two cols: group_id and stem_id, so we can
have
> referential integrity)?
>
> Thoughts?
>
> Regards,
> Chris
>
> Ps. Yes I am trying to get my money's worth out of ddlutils... :)
>
> > -----Original Message-----
> > From: Tom Barton
[mailto:]
> > Sent: Tuesday, December 09, 2008 4:48 PM
> > To:

> > Subject: [grouper-dev] Grouper design call, Wednesday, 10 December
> > 2008, 1200EST (1700Z)
> >
> > Wednesday, 10 December 2008, 1200EST/1700BT/1800CET (1700Z), 60
> minutes
> >
> > +1-866-411-0013 (toll free US/Canada Only)
> > +1-734-615-7474 (Non-US/CA, non-toll free, no dialout)
> > http://edial.internet2.edu/call/0109331 (SIP)
> > PIN: 0109331 (followed by "#")
> >
> > Agenda:
> >
> > 1. administrivia
> > . <http://www.internet2.edu/membership/ip.html>
> > . agenda bash
> > . approve minutes
> > . review AIs
> > . next meeting
> >
> > 2. releasing 1.4.0
> > . bugs & fixes to code & doc
> >
> > 3. potential 1.5.0 work items
> > . Ldappc 1.5.0 - features, direction, post-signet, maven
> > . Audit - discuss Chris' proposal
> > <https://wiki.internet2.edu/confluence/display/GrouperWG/Auditing>
> > . Namespace Transition Support - need a proposal
> > . changes to WS?
> > . changes to Loader?
> > . Subject 1.0?
> >
>
<https://wiki.internet2.edu/confluence/display/GrouperWG/Grouper+Produc
> > t+Roadmap>
> >
>
<https://wiki.internet2.edu/confluence/display/i2miCommon/Roadmap+for+I
> > 2MI+Common+Products>
> >
> > 4. other items
> >
> > 5. new AI review
> >
> > Tom




----------------------
GW Brown, Information Systems and Computing




----------------------
GW Brown, Information Systems and Computing


Archive powered by MHonArc 2.6.16.

Top of Page