Grouper Developers Forum

[Tom Barton <>]

Shilen Patel wrote:
> Tom Barton wrote:
> In my example, this was the biggest performance win because the "ECON" 
> stems were several stems down from the root stem.  As long as the group 
> name (or some other attribute of the group that's available) is named 
> like it is now with the location, this should not constrain options to 
> move and copy stems and groups.  However, every group and stem name from 
> the source hierarchy would have to be updated, but maybe that's okay 
> given the kind of operation taking place?

I suppose so.

> > I can't think of a downside to pre-fetching group attributes.

Beyond the space they take up, compared to a list of UUIDs. So this is a 
clear space/time trade-off. Could you arrange to observe jvm memory 
usage with a search that nets an even larger number of groups, try to 
get a sense of how much of a trade-off?

--

It seems that member caching is clearly a Good Thing, that trying to 
push privilege checking down into the SQL layer breaks the model of 
independent privilege-checking (we want to eat our own dog food, after 
all), and that we can live with using names to determine relative 
location. All that remains is a little look over our shoulders at the 
size of the space/time trade-off.

Thanks,
Tom