jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "harvey waters" <harvey.wat...@googlemail.com>
Subject Re: DM Rule #3: Workspaces are for corresponding nodes.
Date Wed, 11 Jul 2007 07:33:40 GMT
They are very  similar but an audit log includes all the reads as well as
writes (version history). A lot of organisations have to have an audit log
for legal reasons, it would be nice to add it as a system function as a lot
of 'enterprise' type solutions need this kind of functionality.

On 7/10/07, Mark Waschkowski <mwaschkowski@gmail.com> wrote:
>
> Hi Harvey,
>
> What is the difference going to be between your audit log and a version
> history, btw?
>
> Mark
>
> On 7/10/07, harvey waters <harvey.waters@googlemail.com> wrote:
> >
> > I was thinking of it in a slightly different way. I could use the audit
> > work
> > space to store the corresponding audit node in (which has the same uuid
> as
> > the node in the data workspace which holds the actual data) as opposed
> to
> > simply stuffing the audit trail in a 'bucket' .  The corresponding node
> > would have a number of child nodes which would be the actual record of
> an
> > access.
> >
> > I guess I'm trying to sperate the two aspects of the node because the
> > audit
> > trail would never be included with the searches in the 'data' workspace
> > and
> > I have a nagging doubt that the audit trail (which could become huge)
> > could
> > effect the performance of the 'data' workspace.
> >
> > In the perfect world though I know I would store the audit trail with
> the
> > actual node so that I could just use node.getAuditTrail()  or have you
> > guys
> > already included that in jsr283 :)
> >
> > On 7/10/07, David Nuescheler <david.nuescheler@gmail.com> wrote:
> > >
> > > Hi Harvey,
> > >
> > > > So an 'audit log' would be a good reason to setup a new workspace.
> > We're
> > > > thinking here that the audit log is a different perspective (or
> > perhaps
> > > > aspect) of the node in the main 'data workspace'.
> > > I don't think that generally speaking an audit log for a "main data"
> > > workspace
> > > would benefit from an individual workspace. Segmenting by "content
> type"
> > > generally is not a good usecase for workspaces.
> > >
> > > "Corresponding nodes" (as specified in the JCR spec) are essentially
> > > nodes with the same UUID in different workspaces, not nodes that
> > > are related to each other.
> > > I would not expect any "corresponding nodes" in an audit log, but may
> > > I am overlooking something here.
> > >
> > > Personally, I would recommend to have a "/myapp/auditlog" node in the
> > > "main data"
> > > workspace to record all the information there.
> > >
> > > > Is it possible to get a session to write to two workspaces within a
> > > > transaction, surely this must be possible as versioning occurs
> within
> > a
> > > > transaction ?
> > > Versioning is a little bit different since it is handled inside the
> > > repository.
> > >
> > > It would be possible to have two sessions, and enroll both into the
> > > same XA transaction. However, for the audit log application I would
> > really
> > > recommend to keep it simple and store the information in the same
> > > workspace unless there is a good reason not to do that.
> > >
> > > regards,
> > > david
> > >
> >
>
>
>
> --
> Best,
>
> Mark Waschkowski
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message