COmanage Developers List

[Scott Koranda <>]

On Thu, Apr 12, 2012 at 10:55 PM, Benn Oshrin 
<>
 wrote:
> On 4/12/12 11:01 AM, Scott Koranda wrote:
>>
>> Because the propose change "just works" for the standard code
>> base and makes the Grouper plugin significantly faster and
>> less brittle I ask that we make that change. In my opinion the
>> reward outweighs the cost of having some URLs longer with a
>> UUID instead of a simple integer.
>
>
> I assume you're proposing we just make this change for co_groups
> and co_group_members?

Yes.

>
> I understand that this simplifies things for Grouper, but there's a bit of
> the tail wagging the dog there... we shouldn't rearchitect how we do things
> because of one integration.

It's not re-architecting. The role of the id does not change, just its
representation.

> I'm extrapolating a bit here because I'd rather
> not have ids managed different ways for different models

Why? It does not change how you code. You access the id in the same
way as manipulate it in the same way.

> -- if we make the
> switch for groups and group members, we should do it across the board.

No, I disagree.

>
> And I'm not sure we should. It's going to make URLs much uglier, not just
> for /foos/edit/4f871383-c6a0-487c-9060-10e75bb7f614, but where we pass in
> things like CO ID
>
>
> /foos/edit/4f871383-c6a0-487c-9060-10e75bb7f614/co:4f871383-c6a0-487c-9060-10e75bb7f614
>
> or CO ID and COU ID
>
>
> /foos/edit/4f871383-c6a0-487c-9060-10e75bb7f614/co:4f871383-c6a0-487c-9060-10e75bb7f614/cou:4f871383-c6a0-487c-9060-10e75bb7f614

That's a strawman. We do not need to change it for anything but
CoGroup and CoGroupMembers.

>
> Furthermore, there has been some discussion on the list about performance
> penalties for switching to UUID for larger installations. Not something we
> need to worry about right now, but I'd rather not prevent us from scaling
> properly.

Yes, for very large installations. We will not be scaling that far in
any future I can see and if we do we will need to rethink a number of
things.

>
> Perhaps we can come up with an alternate approach to simplify your
> integration?

I have put in an RFE to the Grouper dev team for an auto-incrementing
integer attribute type, but that is not going to happen for a while.

>
> (Again, for demo purposes, you may want to just go ahead with this approach,

I am going ahead.

> and we can add this to the agenda for the f2f.)
>

Ok.

Scott