[Developers] Unique timestamps?

[Jonathan W. Lowe]

On Fri, 2008-02-01 at 13:23 -0800, Tim Sturge wrote:
> Yes; the timestamps of objects (that is the result of the "timestamp" 
> field in)
> 
> [{ "id": null,
> "timestamp": null
> }]
> 
> are all unique; the subsecond fraction is more like a sequence number 
> than an actual number of milliseconds.

Great -- and useful to know about the milliseconds detail.
> 
> If you're syncing with another database you might consider using the 
> "guid" field
> 
> [{ "id": null,
> "guid": null
> }]
> 
> rather than the timestamp. This is designed to be a unique identifier 
> for the object in freebase which is what a replication routine probably 
> wants rather than relying on an implementation decision for timestamps.

Thanks, Tim.  I understand what you mean regarding guid, but am not
replicating everything, only a pair of related types, and am translating
Freebase's append-only rules into a temporal relational database (rather
than another graph) such that history (such as cotype
additions/deletions, BLOB-to-topic reassignment, etc.) is preserved in
the RDBMS.

For example, the same guid might appear, disappear, and then reappear in
a scenario where a user adds Description text (i.e. a text/html BLOB) to
a topic, then later edits it, then later still, decides to revert back
to the original description text.

(If this sounds painful, that's because it is.  There are at least ten
different change conditions you have to track to accomplish this.) But,
there's a payoff.  Because the topics/types I'm replicating are
geospatial, users will be able to "roll back" the map to a particular
moment in time, or watch map features appear, shift and disappear in a
time-lapse sequence corresponding to Freebase activity.  Fields such as
archeology, geology, emergency response, oil & gas and transportation
management need this sort of capability.  And recently, legal disputes
around what a map looked like at the time it supported some disputed
decision have "implicated" digital spatial data providers.

At any rate...if you have an idea for trapping this kind of history by
guids alone, I'd love to hear about it, as the timestamp approach
involves an awful lot of rules and logic.

> 
> Tim
> 
> 
> 
> Jonathan W. Lowe wrote:
> > In coding a replication routine between Freebase and a remote database,
> > I've been relying on the many timestamps associated with topics and
> > links to order the processes, and have assumed that these timestamps are
> > unique across all of Freebase.  So far, my routine hasn't encountered
> > any instances of simultaneous events, but I'd like to turn my assumption
> > into certainty.
> >
> > Seems like the answer has to be that all timestamps are forced to be
> > unique in order to avoid transactional collisions. For instance, there
> > must be some mechanism, even a random choice, that deals with the
> > (however unlikely) scenario in which one user tries to adds a link to
> > one topic at exactly the same instant another user unwittingly attempts
> > to delete that same topic.  In such a scenario, would Freebase
> > arbitrarily designate one of these two write queries as the first,
> > perform its transaction, then evaluate the second write query based in
> > part on the outcome of the chosen first query?
> >
> > There must be a clever MQL query that would answer this unique timestamp
> > question.  If only I were a clever boy.  :(
> >
> > Thanks,
> > Jonathan
> >
> > ----------------
> > Jonathan W. Lowe
> > Giswebsite LLP
> > London, UK
> > http://www.giswebsite.com
> >
> > _______________________________________________
> > Developers mailing list
> > Developers at freebase.com
> > http://lists.freebase.com/mailman/listinfo/developers
> >   
> 
>