You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Michael Dürig (JIRA)" <ji...@apache.org> on 2014/11/25 10:06:12 UTC

[jira] [Created] (OAK-2291) Associate user defined values with checkpoint

Michael Dürig created OAK-2291:
----------------------------------

             Summary: 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)