Thank you, that worked fine.
One question of curiosity is, when you walk a VersionHistory and get a
version. The properties set (when done between checkin and checkout ops) for
a node, don't actually live on the version object but on a child of the
version. It appears in my testing that there is only one child of a version
History, even tho it is accessed thru iterator. Am I correct in
understanding that there is only going to be one child of the Version object
(under normal checkin/checkout) usage?
----- Original Message -----
From: "Jukka Zitting" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Saturday, February 16, 2008 9:03 AM
Subject: Re: non versioned attributes on versioned nodes?
Hi,
On Feb 16, 2008 3:33 PM, Dave Brosius <[EMAIL PROTECTED]> wrote:
I have achieved partial success storing audit info in a child node's
stream
property. As this stream is a serialized object, it is easy to append
audit
information to it.
Ah, OK. A binary property is a good place for a serialized object.
One associated problem, is that sometimes i receive a UUID of the parent
document object to perform operations on, and sometimes i receive a UUID
of
a version of that parent document (by design). In either case, i want to
add
audit information regarding this operation. The problem is the audit
object
is hanging off the parent document, not the version, and so if passed a
UUID
of a version, i need to find the owning document and then navigate to the
child audit object.
[...]
how to I go from the Version to the Node?
You could do something like this:
Node node = session.getNodeByUUID(...);
if (node.isNodeType("nt:version")) {
node = session.getNodeByUUID(
node.getProperty("jcr:frozenNode/jcr:frozenUuid").getString());
}
Note that the version storage can contain version histories of nodes
that do not exist in the workspace you are accessing.
BR,
Jukka Zitting
