Grouper Developers Forum

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

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