Grouper Developers Forum

["Tom Zeller" <>]

On Wed, Jun 11, 2008 at 1:09 AM, Chris Hyzer <> wrote:

2. There are lots of queries going on for each operation.  E.g. to add a member to a group, it is multiple queries (e.g. above).  And if each of those queries results in an audit query, and each audit query goes to the DB for a sequential ID, and potentially reads more info, I don't see how we aren't going to have a slow down by a factor of 1.5-3 (depending on the operation).  But of course we can test this.

Audit queries...I was thinking that's phase 2 (e.g. later)

 

3. I think packing data in a field (e.g. the LDIF design) to be extrapolated later by systems frequently sounds good at first, but later it might be wished to be relational.  If we are storing all data about what has changed, how about we:

a. Make a table for each table we want to track
b. Insert a "shadow" record in the appropriate table for each DB operation
c. This would be done in java, but for people who want high performance, they could turn off the java part and just use triggers (this should make significantly faster)

Would the shadow table have essentially the same schema as the 'original' table but with a timestamp column ? or maybe one or two more columns for other metadata ?

Any thoughts regarding using p6spy to log database activity ?

TomZ