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] [Resolved] (OAK-2291) Associate user defined values with checkpoint
Date Tue, 02 Dec 2014 12:01:13 GMT

     [ https://issues.apache.org/jira/browse/OAK-2291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Michael Dürig resolved OAK-2291.
--------------------------------
       Resolution: Fixed
    Fix Version/s: 1.0.9

Thanks Marcel! Resolving as fixed thus.

> 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
>             Fix For: 1.0.9
>
>
> 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