Open pmorrill opened 4 years ago
Support for this parameter is now in place, for all API calls. When you are ready we will test it by updating some species / list / file records and you can try pulling data to merge the changes into your sqlite file. Just let me know when you want to try that.
The 'custom list' entrypoints support it as well, so you can sign in using your own account and then manipulate your lists (on the website) to test the api data calls.
I'm not too sure if this query will return the entire dataset or just those that are changed. For example if a specie's name with id=1 is changed will I get just the id and name or id,name,scientificname..etc I was hoping we could do the latter. This is because I wouldn't expect large amounts of data either way and it would save me a lot of code from mapping the returned field names and the sql field names. I would also have to build the update queries dynamically from the mappings as well as the number of fields to update.
When you see a 'modified' record, it will be the entire record. All fields will be returned so you can just REPLACE the original record with the new one, entirely. Using the 'id' field as the primary key.
To minimize data flow / bandwidth use, certain queries in the api need to process an 'ifModifiedSince' request parameter. Not all queries will be able to benefit from this, but as a minimum these will:
/projects /species /speciesImages /speciesMaps /speciesSounds
I will also look at the following, which may be adapted to use the parameter:
/projectRegions /speciesRegions /fileRegions
This parameter will allow us to reduce data flow to modified or new records when the app project starts up with an existing local database. But, it will not help in certain situations, particularly if a record is deleted, or disabled. Such events are very rare.
The planned parameter value is a UNIX timestamp (data type Long), which is provided by the 'serverTimeStamp' field in the /info response package.