Grouper Developers Forum

[Chris Hyzer <>]

> I could make an assumption that most consumers would want to know
> the direct changes -- not flattened.  Presently openldap, AD,
> and Google support nested groups.  I can't see any reason we'd
> flatten memberships of groups exported to any of them.  Is there
> a survey somewhere that suggests grouper users are clamoring for
> flat memberships?  If there are, let those who need them suffer
> the overhead.

We offer flattened or unflattened to change log consumers.  If you can 
process unflattened, go for it.

> 
> >> we would use the same flattened representation for point in time audit
> 
> This at least doubles the space used by the flat tables, as they now 
> have audit entries as well as flat table entries.  So adding the 100.000
> member group as a member causes 200,000 inserts.  And when that group is 
> removed as member we get 100,000 deletes and 100,000 inserts.  

Might not be the current plan... when you add 100,000, it cause 100,000 
inserts.  But when removed, you are correct, 100k insert and 100k deletes, if 
you have PIT enabled for that group/folder/whatever.  If you don't care about 
PIT for that group, then it will be 100k insert on membership add, and 100k 
delete for membership delete.

> 
> The utility of the flat table as an audit tool seems overrated to
> me for a couple of reasons.  A detailled point-in-time audit is rare
> enough that a bit of complexity and computation would be acceptable.
> An investigator probably wants the specific group that someone
> was added to or removed from -- not just the resultant effective
> membership.  

If the security is setup so that a certain group or role is used for access, 
then the user will not care how the subject is in the group, immediate / 
effective / etc.  I can see your use case, but I think the flattened 
membership use case will be very common also.

> to synchronize.  So there is a time before which an entity is not
> in a group; a period when the entity maybe is, maybe is not; and
> a time after which the entity is in a group.  It all depends on
> the client's viewpoint.

Right, I think that if there is a lot of churn on memberships, the PIT will 
be more cloudy.  If there is not a lot of churn, then it will be more useful.

> 
> If I add, say Bob, to my group and then, before your change daemon
> comes along I remove Bob from my group, does the flat audit table
> correctly show Bob's brief effective memberships?

We've discussed this, and are ok with some edge cases slipping through the 
cracks for the first implementation of the PIT...  the non-PIT auditing is 
transactional, so if you have an add/remove/add/remove, and you know to look 
there, it could help sort out some of those issues.

In any case, as we discussed in our last dev call, lets performance test it 
and see how it does and we can take it from there.

Thanks!
Chris