Subject: Grouper Developers Forum
- From: "Tom Zeller" <>
- To: "Chris Hyzer" <>
- Cc: "Grouper Dev" <>, "" <>
- Subject: Re: [grouper-dev] changelog implementation sketch
- Date: Fri, 30 May 2008 14:55:41 -0500
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=H4iihvSmNTCTn4xs5NQGtLg0PcWQkiplE7FjFHXTaexLQMyBda9t4mKLWqQDR+/bsBj5X/lBGYuR3UQsPUybg3HB5qXNmy6edRXBkfCyuc1g4wjEnuaC6fbxmf+oC+bWuOmUjh9fCIsJadrtd16YDqn+OJOmxa07fnF4xrpRn7w=
Please see comments inline.
I was thinking of the auditing could be used to see who did what when from where.
So, not considering the use of this for systems to stay in sync with grouper, it would be one table and the columns could be something like:
category (e.g. group),
description (e.g. group created with name 'whatever:whatever' and description 'this is the des…' and friendly name 'Whatever stem: Whatever Group'),
system (prod_ui, test_web_service, my_gsh),
Note that the behind the scenes changes to the registry might not need to be added (e.g. that GrouperAll was added as a member). Its more just what users / clients do from an external perspective…
I agree that the table would need to auto-delete some old records, since these grow large. So I would think that recreating the point in time wont be possible (or are we planning on working backwards?) right?
I think a requirement should be that this thing should be gentle on system performance. If we are writing files, storing multiple rows, etc it might take a performance hit…
Also, from an architecture perspective, I am all that keen on storing local files. If you wanted a hot/standby redundancy setup, now the disk is involved, instead of the DB…
- changelog implementation sketch, Tom Zeller, 05/30/2008
Archive powered by MHonArc 2.6.16.