[Developers] timestamp uniqueness

[augusto callejas]

i noticed the 4 digits, what i was wondering if freebase was using
up to millisecond precision (3rd digit after decimal point), and then  
using the
last digit as a counter.  what you're saying is the precision is only
to the second and all 4 digits are used as a counter.  is that correct?

if so, does that means i shouldn't interpret anything past the decimal  
point
as being an actual sub-second value, but just a counter value?


On Apr 17, 2009, at 3:42 PM, Kurt Bollacker wrote:

>
> On Fri, Apr 17, 2009 at 12:24:37PM -0700, augusto callejas wrote:
>> another way i could ask my question is
>> what guarantee is there for links that have
>> the same timestamp up to the millisecond?
>
> You'll notice that there are 4 digits after the second, not three.
> Also, it is my understanding that these four digits represent a "write
> serial number" within that second.  If it was 1/10 of a millisecond
> indicator, you'd see an almost random distribution of values, but in
> reality, you only see low numbers.  I don't know what happens if more
> than 10,000 writes per second to Freebase were to occur.
>
> 								Kurt :-)
>
>
>
>
>
>> empirically, i have seen two types:
>>
>> 1) the update of a unique property that results in a delete link
>> followed by an insert link.
>> 2) insert of a new node that results in a series of insert links
>>
>>
>> On Apr 17, 2009, at 12:11 PM, augusto callejas wrote:
>>
>>> hi-
>>>
>>> i've noticed when a unique property is updated,
>>> that a delete occurs followed immediately by an
>>> insert, with timestamp value +.0001.  (this insures
>>> the same timestamp up to the millisecond value)
>>>
>>> my question is if another unique property is
>>> immediately updated afterwards, will its
>>> delete/insert links have a unique timestamp
>>> up to the millisecond value compared to the
>>> previous timestamp?
>>>
>>> that is, would i expect link timestamps like:
>>>
>>> 2008-08-20T05:27:45.0000Z delete
>>> 2008-08-20T05:27:45.0001Z insert
>>> 2008-08-20T05:27:45.0010Z delete
>>> 2008-08-20T05:27:45.0011Z insert
>>>
>>> first two delete/insert have same timestamp up to the millisecond
>>> value,
>>> while last two delete/isnert have same timestamp up to the  
>>> millisecond
>>> value.
>>>
>>> or could i see:
>>>
>>> 2008-08-20T05:27:45.0000Z delete
>>> 2008-08-20T05:27:45.0001Z insert
>>> 2008-08-20T05:27:45.0002Z delete
>>> 2008-08-20T05:27:45.0003Z insert
>>>
>>> all delete/inserts have the same timestamp up to the millisecond
>>> value.
>>>
>>>  {
>>>    "master_property" : "/business/company/founded",
>>>    "operation" : "delete",
>>>    "source" : {
>>>      "guid" : "#9202a8c04000641f8000000005f43a01"
>>>    },
>>>    "target_value" : {
>>>      "value" : "2006-08"
>>>    },
>>>    "timestamp" : "2008-08-20T05:27:45.0000Z",
>>>    "type" : "/type/link",
>>>    "valid" : null
>>>  },
>>>  {
>>>    "master_property" : "/business/company/founded",
>>>    "operation" : "insert",
>>>    "source" : {
>>>      "guid" : "#9202a8c04000641f8000000005f43a01"
>>>    },
>>>    "target_value" : {
>>>      "value" : "2007-08"
>>>    },
>>>    "timestamp" : "2008-08-20T05:27:45.0001Z",
>>>    "type" : "/type/link",
>>>    "valid" : true
>>>  }
>>>
>>> thanks,
>>> augusto.
>>> _______________________________________________
>>> Developers mailing list
>>> Developers at freebase.com
>>> http://lists.freebase.com/mailman/listinfo/developers
>>
>> _______________________________________________
>> Developers mailing list
>> Developers at freebase.com
>> http://lists.freebase.com/mailman/listinfo/developers
> _______________________________________________
> Developers mailing list
> Developers at freebase.com
> http://lists.freebase.com/mailman/listinfo/developers