Meaning of fsVersion field in familysearchtable (RM8)
The RM8 familysearchtable has a column called 'fsVersion'. Does anyone know what this is for? The highest values I can find for it do appear to reflect the most recent updates to Persons, but I cannot work out what the value actually represents.
I have a feeling that RM is somehow using this when identifying FamilySearch updates in 'What's New' (especially given that this functionality seems to be what populates it), but none of the documented FS APIs mention this data item, so perhaps it is local to RM rather than generated by FS.
It would in particular be really useful to be able to translate the fsVersion into a date or (even better) timestamp (while the left hand side of it does look like a Unix timestamp, I suspect this is a red herring; the value doesn't in any way correspond with any Unix timestamp present in the relevant Person JSONs as delivered by FS).
Thanks.
I don't know, and I had never looked at that field before.
I'm using RM9 rather than RM8, but I doubt that it makes a differences. In my database, there are multiple formats for the fsVersion data. It is sometimes blank (or null?). It is sometimes "short" and sometimes "long". All the short instances are the same length and all the long instances are the same length. A few but not all of the short instances include a -gzip suffix. All of the long instances include
a -gzip suffix.
Thanks, that's very interesting.
It's definitely not populated until What's New first checks it. The Modified column, I am pretty sure, identifies those entries that are counted as 'New' by the RM8 user interface at any given time.
I have seen none with -gzip or anything other than numbers; mine all look like this:
| fsVersion |
|---|
| 139083900301820000 |
| 139110072916550000 |
| 139044976917750000 |
| 139044976918620000 |
| 138265615520050000 |
| 139091645721580000 |
| 138868394152700000 |
I've only ever used RM8 though, not RM9.
Here's a sample from my database.
Uploaded files:
Interesting
does not look like it coincides with UTCModDate -- and some are blank on mine. Might be like an internal timestamp on the FS side.
see screen snip
Uploaded files:
I think I have now got to the bottom of this for RM8.
If you extract the 'version' value in the FS Person JSON (this is unique for a Person, and is specific to the 'to' citation for this Person's Family Tree entry), fsVersion always matches the following formula:
(version+12219292800000)*10000
except for the rightmost digit of fsVersion (which is almost always zero, but occasional values of 1-4 appear in my data).
'version', like all other FS timestamps as far as I can see, is a Unix timestamp with 3 additional digits at the right hand end, presumably for milliseconds.
fsVersion can therefore be visualised in SQLite, to the seconds level, as
datetime(substr(fsVersion/10000-12219292800000,1,10),'unixepoch')
The 'version' timestamp does not, it has to be said, always indicate the latest date/time for this Person as a whole; conversely, it may represent a change in the FS back end that we cannot see; but it definitely appears to me (for RM8) that the logic for populating fsVersion is as I have just given it (tested against c.600 Persons with a 4 year range of 'version' timestamps).
The UTCModDate is clearly different (and, unhelpfully, appears to be readable as a timestamp by Excel but not directly by SQLite).
Good sleuthing, Mandy!
As for UTCModDate, see Date Last Edited - UTCModDate
Brilliant thanks Tom.
@mandyshaw that make sense --I figure it w was some unique "Code"
so it the version had changed there might be things to review.
RM(8 or 9) 'fsVersion' <> the FamSearch side.
RM8 is clearly using fsVersion when identifying FamilySearch updates in 'What's New' (this functionality in fact seems to be what populates fsVersion), with the associated 'Modified' column, when set to '1', being what populates the What's New 'View' list (I have succeeded in manipulating this list by setting Modified with a SQLite update statement).