Currently, the weather files are derived (I think) from CMPI5 data. There is now a CMIP6 version of them. We wish to host and provide both sets of data.
There may be some difference in locations, files, etc., between the two versions. HOWEVER, for the purposes of thinking and coding, we should regard this as two sets of the same locations and the same kinds of files per location, distinguished only by something we will call "version", which will in the next iteration take the values "CMIP5" and "CMIP6".
The indexing database is quite simple in structure. There are locations and there are files, which are associated to a location. So we have the following tables
locations
files
summary_files
wx_files
The only complication here is that files is polymorphic (like ancestor and child classes), indicated by the indents in the list above. But that shouldn't complicate things.
To handle multiple versions, each file (so, table files) will need a version column. That column could be an enumeration type, or it could be an association to a (new) table versions. I favour the latter because it makes adding a new version in future much simpler ... no schema migration required, just a new row in the version table.
each file response item have a version field added
the /files endpoint accept a version query param, which it uses to filter the returned
Filtering here in the backend may not be necessary depending on how we decide to process and present info in the frontend. Given the relatively small number of locations and files, so small response size, it may be adding complication to no real benefit.
Currently, the weather files are derived (I think) from CMPI5 data. There is now a CMIP6 version of them. We wish to host and provide both sets of data.
There may be some difference in locations, files, etc., between the two versions. HOWEVER, for the purposes of thinking and coding, we should regard this as two sets of the same locations and the same kinds of files per location, distinguished only by something we will call "version", which will in the next iteration take the values "CMIP5" and "CMIP6".
The indexing database is quite simple in structure. There are locations and there are files, which are associated to a location. So we have the following tables
locationsfilessummary_fileswx_filesThe only complication here is that
filesis polymorphic (like ancestor and child classes), indicated by the indents in the list above. But that shouldn't complicate things.To handle multiple versions, each file (so, table
files) will need a version column. That column could be an enumeration type, or it could be an association to a (new) tableversions. I favour the latter because it makes adding a new version in future much simpler ... no schema migration required, just a new row in theversiontable.In the API (spec, code), I suggest that:
versionfield added/filesendpoint accept aversionquery param, which it uses to filter the returnedFiltering here in the backend may not be necessary depending on how we decide to process and present info in the frontend. Given the relatively small number of locations and files, so small response size, it may be adding complication to no real benefit.