Skip to Content.
Sympa Menu

grouper-dev - RE: [grouper-dev] Action Items: Grouper Call 7-July-2010

Subject: Grouper Developers Forum

List archive

RE: [grouper-dev] Action Items: Grouper Call 7-July-2010

Chronological Thread 
  • From: Chris Hyzer <>
  • To: Jim Fox <>, Shilen Patel <>
  • Cc: Tom Barton <>, Grouper Dev <>
  • Subject: RE: [grouper-dev] Action Items: Grouper Call 7-July-2010
  • Date: Tue, 13 Jul 2010 12:30:49 -0400
  • Accept-language: en-US
  • Acceptlanguage: en-US

> 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.


Archive powered by MHonArc 2.6.16.

Top of Page