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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
