Grouper Developers Forum

["GW Brown, Information Systems and Computing" <>]

I'm happy to have separate files but if we can wrap it with the existing 
import / export commands that keeps functionality where it would be 
expected. Additional args can control behaviour e.g.
-audit <file> or -auditonly <file>.

Gary

--On 18 March 2009 14:40 -0400 Chris Hyzer 
<>
 wrote:

> Is it ok with people if import/export of user audits is a different file
> (and different command) than the existing import/export file?
>
>
>
> I think the advantages are:
>
>
>
> 1.       The file can already be big, and this auditing table could also
> be big, so splitting might help us not hit some limits
>
> 2.       I haven't really looked at the current import/export
> implementation, but I would like to make this one tuned to perform, so
> you can import/export the audit records very quickly and without
> requiring a lot of memory
>
>
>
> The disadvantages are:
>
>
>
> 1.       If users are used to import/export being complete, then they
> need to remember to import/export audits also.
>
>
>
> Note: there are no DB foreign keys from auditing to the other tables or
> vice versa…  though you cant just take the audit info and use it, e.g.
> you need to dereference member_ids…  and changes in member_id are
> audited, so you should always be able to get back what you need)
>
>
>
> I will be asking the same question about point in time auditing as
> well…
>
>
>
> If we want to use the same command, and keep separate files, we could
> have the main command generate a zip of the 3 (or more) underlying
> files… (Java has zip support and this is what we do at Penn to
> aggregate files)
>
>
>
> Thoughts?
>
>
>
> Thanks,
>
> Chris



----------------------
GW Brown, Information Systems and Computing