Skip to Content.
Sympa Menu

grouper-dev - RE: [grouper-dev] import/export of user audit records

Subject: Grouper Developers Forum

List archive

RE: [grouper-dev] import/export of user audit records


Chronological Thread 
  • From: "GW Brown, Information Systems and Computing" <>
  • To: Chris Hyzer <>, Grouper Dev <>
  • Subject: RE: [grouper-dev] import/export of user audit records
  • Date: Wed, 18 Mar 2009 19:45:26 +0000

Yes that's right. Of course the audit stuff can invoke new classes, use SAX rather than DOM etc.

Gary

--On 18 March 2009 15:41 -0400 Chris Hyzer
<>
wrote:

You are saying that the existing xmlimport/export commands should work,
and you just specify more params as to the filenames, right? So one
command could export the registry, and audits, and they go to multiple
files. And one command could import, but you specify multiple files, and
it does it all at once.

Sounds good to me.

Thanks.
Chris

-----Original Message-----
From: GW Brown, Information Systems and Computing
[mailto:]
Sent: Wednesday, March 18, 2009 3:38 PM
To: Chris Hyzer; Grouper Dev
Subject: Re: [grouper-dev] import/export of user audit records

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




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




Archive powered by MHonArc 2.6.16.

Top of Page