Grouper Developers Forum

["GW Brown, Information Systems and Computing" <>]

--On 21 January 2005 11:33 -0800 blair christensen <> 
wrote:

> On 2005.01.21 08:52, Tom Barton wrote:
> > Bugzilla #271 is to complete support for groups having multiple types.
> > Until that's there, the single type they're allowed must have everything
> > in it.
>
> Once I've cleaned up some bugs and made some additional internal
> cleanups, adding proper support for multiple group types is one of the
> first things I intend to add in.
>
> > > 2) The uniqueness of the 'name' attribute is not enforced - two groups
> > > with different types can have the same name.
> > >
> > > I can see that a stem (implemented as a group) might have the same
> > > name  as a group, but having actual groups be able to have the same
> > > name would  be confusing and create problem instantiating a group by
> > > name, as  discussed in 3.
>
> Would you want names to be unique across all group types or just
> between stems and all other group types?
As stems are logically distinct from groups we ought not to stop them 
having the same name, but actual groups should have unique names.
> > Witrhout looking into the specifics, I know that we arrived at the final
> > naming model too late to get it all baked into the 0.5 release. I assume
> > this issue is an aspect of that fact.
>
> The 0.5 naming model is subpar, partially due to time constraints and
> what not, and should be improved with future releases.
>
> > The only unambiguous way of referring to a group is by
> > its guid (value of GrouperGroup.id).
>
> Right.  In the current design, the group id is much better handle than
> the group name.  The name is mutable but not the id.
OK . May be raises the question as to whether there ought to be methods 
that load by name if that is 'unsafe'?

> blair.



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