jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig (JIRA) <j...@apache.org>
Subject [jira] [Commented] (OAK-2291) Associate user defined values with checkpoint
Date Mon, 01 Dec 2014 14:40:12 GMT

    [ https://issues.apache.org/jira/browse/OAK-2291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14229851#comment-14229851
] 

Michael Dürig commented on OAK-2291:
------------------------------------

At http://svn.apache.org/r1642692 I committed above API extension and initial implementations
for {{MemoryNodeStore}}, {{SegmentNodeStore}}, {{ProxyNodeStore}} and {{KernelNodeStore}}.


* The {{KernelNodeStore}} currently does not support user defined values and throws a {{UnsupportedOperationException}}
on {{checkpoint(long, Map)}}. 

* The implementation for {{DocumentNodeStore}} is still TODO. [~mreutegg], could you help
me out with this one when time permits? 

> Associate user defined values with checkpoint
> ---------------------------------------------
>
>                 Key: OAK-2291
>                 URL: https://issues.apache.org/jira/browse/OAK-2291
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: core
>            Reporter: Michael Dürig
>            Assignee: Michael Dürig
>            Priority: Minor
>
> For diagnosis, upgrade, migration, maintenance, etc. it would be useful if we could assign
user specific properties to checkpoints. This could be used e.g. to record who added a checkpoint
(i.e. backup, indexer, ....). This would simplify action taken for example on the checkpoint
MBean as one could more easily tell various checkpoints apart. 
> I therefore suggest to add the following methods to the {{NodeStore}} API:
> {code}
> /**
>  * Creates a new checkpoint of the latest root of the tree. The checkpoint
>  * remains valid for at least as long as requested and allows that state
>  * of the repository to be retrieved using the returned opaque string
>  * reference.
>  * <p>
>  * The {@code properties} passed to this methods are associated with the
>  * checkpoint and can be retrieved through the {@link #checkpointInfo(String)}
>  * method. Its semantics is entirely application specific.
>  *
>  * @param lifetime time (in milliseconds, &gt; 0) that the checkpoint
>  *                 should remain available
>  * @param properties properties to associate with the checkpoint
>  * @return string reference of this checkpoint
>  */
> @Nonnull
> String checkpoint(long lifetime, Map<String, String> properties);
> /**
>  * Retrieve the properties associated with a checkpoint.
>  *
>  * @param checkpoint string reference of a checkpoint
>  * @return the properties associated with the checkpoint referenced by
>  *         {@code checkpoint} or an empty map when there is no such
>  *         checkpoint.
>  */
> @Nonnull
> Map<String, String> checkpointInfo(String checkpoint);
> {code}
> At the same time we should probably deprecate {{NodeStore#checkpoint(long)}} in favour
or {{NodeStore#checkpoint(long, Map<String, String>)}} passing an empty map as its 2nd
argument. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message