Can you elaborate what you mean by "maintain the health of a database"? If we'd decide that we never want to delete any data in a certain MarkLogic database so that we can roll back to any point in time, what would be the down sides? How would the database become unhealthy?
Please take a look at the docs on merging, specifically the section, "Merges Are Good" <https://docs.marklogic.com/guide/admin/merges#id_43904>. Merging is the way that MarkLogic manages its internal data to support efficient and consistent ingest and query I/O. It is an internal process and completely orthogonal to how you version your documents. What you describe sounds more like temporal versioning. Please take a look at MarkLogic's bitemporal APIs <https://docs.marklogic.com/guide/temporal/intro>. With bitemporal management you maintain an immutable copy of the entire history of your data that you can query at any point in time. The APIs do all of the sophisticated work maintaining versions securely. The "bi" in bitemporal allows you to query the valid time of the document (e.g. a trade was effective on 2016-06-01) as you knew it at any point in time (e.g. the trade wasn't recorded until 2016-06-02 and then it was corrected on 2016-06-05). Justin On Jun 28, 2016, at 9:55 PM, Hans Hübner <[email protected]<mailto:[email protected]>> wrote: On Tue, Jun 28, 2016 at 10:36 PM, Justin Makeig <[email protected]<mailto:[email protected]>> wrote: > as we want to be able to use the point-in-time query feature to track > document changes over time Point-in-time queries <https://docs.marklogic.com/guide/app-dev/point_in_time> are not designed for versioning, as I think you're describing it. The timestamps are internal bookkeeping. (Think of them as monotonically increasing integers rather than wall clock readings.) Querying at specific timestamp relies on _not_ merging deleted fragments. For short windows, like minutes or even hours, depending on your workload, this is OK. However, merging is necessary and useful to maintain the health of a database. Can you elaborate what you mean by "maintain the health of a database"? If we'd decide that we never want to delete any data in a certain MarkLogic database so that we can roll back to any point in time, what would be the down sides? How would the database become unhealthy? We have an existing application that makes use of another database system (Datomic) exactly in that way, and we would like to carry it over to MarkLogic. The "Inside MarkLogic" document describes point-in-time queries as "Time Travel", but what you write seems to say that using timestamps that way would be detrimental to the health of the database, so I'd like to learn more before we convert. Thanks! Hans -- LambdaWerk GmbH Oranienburger Straße 87/89 10178 Berlin Phone: +49 30 555 7335 0 Fax: +49 30 555 7335 99 HRB 169991 B Amtsgericht Charlottenburg USt-ID: DE301399951 Geschäftsführer: Hans Hübner http://lambdawerk.com/ _______________________________________________ General mailing list [email protected]<mailto:[email protected]> Manage your subscription at: http://developer.marklogic.com/mailman/listinfo/general
_______________________________________________ General mailing list [email protected] Manage your subscription at: http://developer.marklogic.com/mailman/listinfo/general
