Skip to Content.
Sympa Menu

grouper-dev - RE: [grouper-dev] reducing the uuid/id pair to identify a row in grouper tables

Subject: Grouper Developers Forum

List archive

RE: [grouper-dev] reducing the uuid/id pair to identify a row in grouper tables


Chronological Thread 
  • From: Chris Hyzer <>
  • To: Tom Barton <>
  • Cc: "" <>
  • Subject: RE: [grouper-dev] reducing the uuid/id pair to identify a row in grouper tables
  • Date: Thu, 31 Jul 2008 12:59:56 -0400
  • Accept-language: en-US
  • Acceptlanguage: en-US

> >
> > 1. Drop the field type from memberships, and in grouper_fields, drop
> > the id and have the name as the primary key. Leave
> grouper_attributes
> > as is. <should be lowest impact solution> This works since field
> > name is unique, so from the name you can derive type.
> > -or-
> > 2. in grouper memberships, drop the cols for list name and
> > type, and add the field uuid. In grouper_attributes, drop the field
> > name and add field uuid.
>
> I'm not getting it. Could you more precisely describe what would become
> the primary key and any indices you'd maintain on these tables under #1
> and #2?


Currently (after uuid col is gone) grouper_fields has a primary key on "ID".
It has a unique constraint on "name", and a unique constraint on "name" and
"type" (for foreign keys). grouper_attributes has a foreign key to
grouper_fields based on name. And grouper_memberships has a foreign key to
grouper_fields based on name *and* type.

In #1, I suggest that the id col of grouper_fields go away, and the "name"
col will be the primary key. The field "type" col should go away from
grouper_memberships, so the foreign key to grouper fields is just the "name"
col, just like grouper_attributes. The "name" can determine the "type" since
name is the primary key.

In #2, I suggest that the grouper_fields table stay the same (except no
unique constraints are needed, only unique index on name and type). The
grouper_memberships table can drop field name and field type, and add the
field "id" to be a foreign key into grouper_fields. The grouper_attributes
can drop field_name and add the field "id" which is a foreign key into
grouper_fields.

Both will of course be done with no noticeable change in the API, and no
performance implications (there are so few fields, they cache fine, and are
already cached). I haven't done it yet, but shouldn't be hard. After
migrating the uuid/id thing, #1 will be easier to migrate since it will not
require updating the memberships table, just dropping a col.

Regards,
Chris







Archive powered by MHonArc 2.6.16.

Top of Page