COmanage Developers List

[Benn Oshrin <>]

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?

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. I'm extrapolating a bit here because 
I'd rather not have ids managed different ways for different models -- 
if we make the switch for groups and group members, we should do it 
across the board.

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

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.

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

(Again, for demo purposes, you may want to just go ahead with this 
approach, and we can add this to the agenda for the f2f.)

-Benn-