Christophe Lombart wrote:
On 10/26/05, Martin Koci <[EMAIL PROTECTED]> wrote:
Previous method getVersionLabels() was mistake, because there is no
'latest' version in JCR. Because version are stored as direct acyclic
graph there is no information which version is the 'newest'.
With simple tests, the newest is not the version provided by
node.getBaseVersion() or VersionHistory.getRootVersion()
I'm reviewing your code and I have some questions and remarks :
1.In the methods checkout, checkin, getVersionLabels, addVersionLabel
: why the object versionableEntity is defined as an argument, it is
not used in the method impl.
versionableEntity can be used to some checks like "this object is not
stored on path".
I would like to use one of the following solution:
* either use only the path
* or either use only the object (if this one contains the UUID or the
path). This imply a small refactoring on the others persistenceManager
methods (as you suggested a couple of days before).
I think JCR is 'path-oriented' (or UUID-oriented) more then
object-oriented. Operations are performed on paths not objects. So i
think general API must always accept path or UUID but can contain method
operating on mapped object:
/**
[EMAIL PROTECTED] if object has no path or UUID mapping
*/
checkin(Object entity) throws NotIdentifiableObjectException
2.checkin : Why to split the version number into a String[]. I think a
simple string arg is more open : checkin(String absPath, Object
versionableEntity, String versionLabel)
Because one version can have more labels. For example in my application
one binary content of document has version labels '1.1' and 'B.1'
3. Following the jackrabbit mailing list, extra version properties
(user, comments, ...) has to be added into the matching node.
Yes, but not in my app. I solved it with domain object Version which
stores additional information of each version.
christophe
