Grouper Developers Forum

["Tom Zeller" <>]

On Thu, Jun 5, 2008 at 9:35 AM, Tom Barton <> wrote:

 

In addition, attribute names should come from the grouper_fields table. In particular, there's no [effective|immediate|composite] variants of a list field - that's a UI presentation thing. 

Regarding the DN, perhaps we should consider a format using a compound RDN. Eg,

dn: name=memphis:courses:physics001.2008,
 uuid=038e36f8-c04b-4679-af79-1bb39806ccba 

I think it's important for the uuid to be there, but also a human-parseable name.

That's good, I had considered both dn: name=x and dn: uuid=x but they both seemed incomplete.

 

I'm hoping that it'll be enough for effective changes to memberships and attributes to all have the same change_number in the table, ie, that we don't need to somehow express in LDIF that "this is an effective change necessitated by the original change X".

Right, LDIF is not really amenable to representing effectiveness, nor might other simple representations.

I have been thinking that change_numbers should be unique (per row) and be auto-incrementing as provided by the database (so we don't have to write code to manage the change numbers), with a parent_uuid column denoting effectiveness and the 'grouping' of changes. However, I've updated the examples as you've suggested and we'll see how it works out.

Thanks,

Tom