version database

[sckott]

Then provide parameter to query based on a certain date for reproducible results

@cboettig worth trying? we sometimes talk about this, but DBs seem to never be versioned, but we can try with this

[cboettig]

Good idea. We could at least emulate this by keeping each snapshot we get from them online at a versioned endpoint in the API. Should probably work to them about following some more regular snapshot interval as well, so far I think we've just been asking for an update whenever a user complains about our version being out of date

[sckott]

Right, that's what I meant by versions, just snapshots - hopefully there's a formal way to swap DB versions quickly

If there's a way to get updates more often, that'd be great, but can keep going as we are if not

[cboettig]

I think we should import each to a separate SQL DB, and then edit the rest API to take an argument which we use to select the right database, just like we currently do to choose between fishbase and sealifebase. Does that sound workable?

[sckott]

Right, that sounds good to me

[cboettig]

Related to this, wonder if we could provide some sort of diff indicating what has changed in the FishBase database with subsequent updates.

[sckott]

We can certainly try

and then edit the rest API to take an argument which we use to select the right database, just like we currently do to choose between fishbase and sealifebase.

hmm, but sealifebase is requested via a path component

Wonder if we should toggle versions with a header - as the Github API does - that way if no header for version is passed the user gets the current version with latest data. Clients like rfishbase though can make the user interface look like a parameter and internally pass the appropriate header. thoughts?

There's the issue of how/where to store the different database versions. Any thoughts on that?

[cboettig]

Putting the version in the header seems really elegant to me, particularly if that's a common pattern for this kind of thing in APIs. (I've never been super pleased with APIs doing that through the URL).

A separate question I suppose is that it would probably be cleaner to put sealifebase on a separate subdomain on the same server rather than serving it off a separate path, but not really a priority.

[sckott]

A separate question I suppose is that it would probably be cleaner to put sealifebase on a separate subdomain

Agree, that would be nice, and if we do any other APIs we could just add new subdomains for those

[sckott]

Working on this now - will push up a new branch soon, getting database version loaded on server cc @cboettig

[sckott]

@cboettig this is live now, let me know if you find any problems