This thread doesn't seem to want to stay on oak-dev@ ;-). I guess this
was my fault. Including the part of the conversation that dropped off
the list below.
On 29.08.17 11:18, Tomek Rekawek wrote:
Hi Michael,
these methods doesn’t provide the information about the creation and expiration
times. I need those to clone the checkpoints in the side grade.
Right, got it. So the discussion to have is whether we should reflect
that information through the checkpoint properties. But let's separate
this from this issue assuming you are fine with the CheckpointAccessor
approach for now.
I'll follow up with an issue/discussion regarding the checkpoint
properties.
Michael
Regards,
Tomek
-- Tomek Rękawek | Adobe Research | www.adobe.com [email protected]
On 29 Aug 2017, at 08:56, Michael Dürig<[email protected]> wrote:
Hi,
Looking at org.apache.jackrabbit.oak.upgrade.checkpoint.CheckpointRetriever I
wonder whether this cannot be implemented on top of already existing APIs:
org.apache.jackrabbit.oak.spi.state.NodeStore#checkpoints and
org.apache.jackrabbit.oak.spi.state.NodeStore#checkpointInfo?
Michael
On 28.08.17 12:41, Tomek Rekawek wrote:
Hello,
the migration code requires access to the checkpoint metadata: the creation and
expiry timestamps. They can be read by accessing the checkpoints root node
(using the method mentioned in the subject). However, the method is
package-scoped. Can we make it public, so the other modules can use it as well?
Alternatively, we may introduce some general way to read that data for all
NodeStore implementations. Maybe some extra properties in the checkpoint
properties?
Regards,
Tomek
