I am currently using Stardog 7.2 version. I heard that stardog has deprecated data versioning and came up with new features similar to bi-temporal modeling. My questions are:
I had previously asked about the possibility of using the new edge-properties feature to do bi-temporal modeling but I don't believe anything has changed with VCS. (Stardog versioning)
What exactly are you looking to do?
I want to know how versioning can be achieved through UI and CLI in stardog. It would be great if share CLI commands here
API https://stardog.docs.apiary.io/#reference/versioning
CLI Home | Stardog Documentation Latest stardog vcs *
Thanks Zachary for replying back, I am not familiar with the API method, need to go through it.
But I tried using CLI commands. First I enabled the database with versioning.enabled=true, then ran few VCS commands. There was a warning stating that the database has to be enable versioning. Help me out in this issue.
I'm running 7.2.0 and I got the same thing. I vaguely recall someone mentioning that it had been removed since they went to the new Mastiff backend but I can't be sure. There's nothing in the docs except the references to the man pages. Someone from Stardog would have to clarify what the status is. I thought that they were possibly working on snapshot support and might bring it back when that was ready.
We deprecated and then removed the lightweight versioning support that existed in earlier versions of Stardog. So the behavior you are seeing is expected; we do not support vcs anymore.
As Zach said, we are currently considering different, but similar functionality, around temporal or bi-temporal access to the data physically held in Stardog. There are a lot of open questions around what are the precise features required for this and how it interacts with virtual graphs.
We'd love to hear about your use case to help inform the feature design process.
One of the challenges in bitemporal design is that the temporal fields need only be monotonically increasing types. A mistake many application designers make is to use CPU derived timestamps; this will produce bad results in multi-process and multi-CPU environments. A better approach is to implement internally transactional monotone generators for use in the temporal fields. If the application really needs to know the time, it can be sampled once when the temporal index is generated and recorded as a property of the temporal index. This allows the bitemporal implementation to use a fixed datatype, and the application developer to use any datatype meeting the monotonic criteria. In the case of complex transactions with many insertions, updates and deletes, the same generated index is used everywhere in the transaction, insuring that the temporal semantics are consistent.
A few years ago, I designed a bitemporal relational database schema for the US Trademark Office to track trademark application cases.
Jim
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.