Grouper Developers Forum

[Shilen Patel <>]

Hi Tom,

One of the issues with that is database constraints.  For instance, in 
the grouper_memberships table, we have a unique key on the owner, 
member, and field.  This ensures that immediate memberships cannot be 
duplicated, which can otherwise happen if two processes add the same 
membership at about the same time.  We had several jira issues on 
that.   If we add start and end timestamps to this table, then this 
unique key needs to be removed or changed to include other fields like 
the start timestamp, but this will result in the same issues we had 
before.  By the way, this concern wouldn't exist for the PIT tables 
because there's just a single process maintaining that table.

Another reason (that may not be an issue but maybe something to 
consider) would be that these tables would become larger and that might 
have a performance impact.

Thanks!

-- Shilen


On 8/12/10 9:00 AM, Tom Barton wrote:
> Shilen,
>
> I have one question for which the answer must be obvious, but I don't
> see it right now. Why have separate tables for flattened notifications
> and PIT, ie, why not just add columns to existing tables for start&  end
> timestamps and active state?
>
> Thanks,
> Tom
>
> On 8/9/2010 11:52 AM, Shilen Patel wrote:
>    
> > Since there were performance concerns about how we handled flattened
> > membership notifications in 1.6 and how we were planning on handling PIT
> > audit in 2.0, here's a new design for how we can handle both in 2.0.
> >
> > https://spaces.internet2.edu/display/GrouperWG/Membership+PIT+audit+and+flattened+notifications+for+v2.0
> >
> >
> > Let me know if you have any questions or concerns.
> >
> > Thanks!
> >
> > -- Shilen
> >      
>