Get the list of changes for your database
Get the list of changes to be replayed on your own copy of Opencaching database. Use this method periodically (e.g. every 5 minutes) to keep your database in sync with ours.
For some applications it might be desireable to have a quick access to the entire Opencaching database (instead of querying for specific portions of it). You may use OKAPI's replicate module to achive this effect. The changelog method is the primary replication service which you will use. However, to correctly set up your first database copy, you will need to use the fulldump method.
A couple of things for you to remember:
Let's assume that you already have a copy of OKAPI database, but it's already 2 days old. You want to use the changelog method to update your copy to the most current state.
Changelog is the list of all changes which appeared in the OKAPI database since the last time you downloaded it. What you have to do is to download this list of changes and to replay them on your copy of our database. After you do this, your database is up-to-date.
We use revision numbers to keep track of all the versions of the database. Every time we update a database, the revision is increased. You will also receive this number every time you fetch a changelog or a fulldump of our database. You must keep this number carefully, because you need it in order for us to generate a proper changelog for you next time you ask for it!
Example. This is a valid list of requests you should issue and their responses:
Current revision of your database. This should be the same as the value of revision attribute, which you received with your previous update.
Old revisions are deleted, the since argument MUST referer to a revision no older than 10 days. You will have to download a fulldump if you have an older copy (shame on you!).
|format||optional||Standard common formatting argument.|
|callback||optional||Standard common formatting argument.|
|Plus required consumer_key argument, assigned for your application.|
A dictionary of the following structure:
The response MAY contain changes recorded before the revision which you stated in your since parameter. This is due to caching. If we already have a response ready, that was produced for a "since" parameter which was a little more in the past, we may want to return this cached copy, instead of producing a new one. It will be faster for us, and you shouldn't even notice. We will still make sure to set the revision and more attributes in a correct way, which in turn will make you query us again, if you need to.