Reputation: 31
I have changed the merge policy for the database. Where I set the merge timestamp as current timesatmp(15181726371585905). After changing the merge policy I updated one docs with same URI and collection. Now when I am trying to fetch the deleted docs I am not getting it. I am getting empty sequence.
xdmp:eval("doc('/docs/test.xml')", (),
<options xmlns="xdmp:eval">
<timestamp>{xdmp:request-timestamp()-1}</timestamp>
</options>)
How to get the deleted docs using above query.
TIA.
Upvotes: 2
Views: 181
Reputation: 8422
Just tried this out and get the newest version, rather than the empty sequence. Here's my understanding of what you're trying to do:
You've set the timestamp to the current time (t), then inserted a document (at time t + m), then inserted a new version of the document at the same URI (at time t + n). You now want to retrieve the document from time t + m.
The problem is the way you're specifying the timestamp for your read request:
<timestamp>{xdmp:request-timestamp()-1}</timestamp>
You're asking MarkLogic to rewind the clock one tick and give you the document that existed at that time. However, timestamps do correlate to clock time; they don't just increment when the database state changes. From MarkLogic's Administrator's Guide:
The ticks are calculated at 10,000,000 ticks per second
So by subtracting one from the current timestamp, you're asking to go back about 1/10,000,000 of a second.
If you know the wall-clock time for when you want to query the database, you can find the corresponding timestamp with xdmp:wallclock-to-timestamp
.
As an aside, you've also asked a question on Stack Overflow about how to track multiple versions of a document. I'd like to caution you not to view point-in-time queries as one of them, if that's what you had in mind. For that purpose, document library services or bitemporal documents are a better solution. For more information on why not to use PIT queries for versioning, I'll refer you to the Overview of Merges section of the Administrator's Guide, particularly the "Dangers of Disabling Merges" and "Merges Will Change Scores" parts.
Upvotes: 2
Reputation: 7770
Setting the merge-timestamp to the current time tells the server to keep fragments from that point on. All documents in the system prior to setting the new merge-timestamp value would logically have a fragment timestamp prior to that time. Therefore, when you update the document, the system no longer makes available the previous versions(because you said to only keep documents with fragment timestamps from now on).
Some references:
Upvotes: 0