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
- reducing the uuid/id pair to identify a row in grouper tables, Chris Hyzer, 07/30/2008
- Re: [grouper-dev] reducing the uuid/id pair to identify a row in grouper tables, Tom Barton, 07/30/2008
- RE: [grouper-dev] reducing the uuid/id pair to identify a row in grouper tables, Chris Hyzer, 07/31/2008
- Re: [grouper-dev] reducing the uuid/id pair to identify a row in grouper tables, Tom Barton, 07/31/2008
- RE: [grouper-dev] reducing the uuid/id pair to identify a row in grouper tables, Chris Hyzer, 07/31/2008
- Re: [grouper-dev] reducing the uuid/id pair to identify a row in grouper tables, Tom Barton, 07/31/2008
- RE: [grouper-dev] reducing the uuid/id pair to identify a row in grouper tables, Chris Hyzer, 07/31/2008
- Re: [grouper-dev] reducing the uuid/id pair to identify a row in grouper tables, Tom Barton, 07/30/2008
Archive powered by MHonArc 2.6.16.