On Tue, Jun 28, 2016 at 10:36 PM, Justin Makeig <[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] Manage your subscription at: http://developer.marklogic.com/mailman/listinfo/general
