search

IBM / cloudant-node-sdk

Cloudant SDK for Node.js
Apache License 2.0
27 stars 13 forks source link

instance_start_time removed from the get database information #1525

Closed tgujrathi closed 1 month ago

tgujrathi commented 1 month ago

With the latest version upgrade, instance_start_time has been removed from the database get information API. We have a dependency on that value.

ricellis commented 1 month ago

Thanks for reporting this and sorry for the disruption.

The instance_start_time was never included in our SDK API model because it was meaningless from CouchDB 2.0.0 and earmarked for future removal.

instance_start_time now always reports "0"

So although it was visible in raw responses it was not part of the API model and undocumented. In the 0.9.0 release we replaced the raw responses with the API models, which is why the instance_start_time was lost.

However, it looks like CouchDB 3.3.2 re-added a value for instance_start_time

#3901: Use db-creation time instead of 0 for instance_start_time to help replicator recognise whether a peer database was deleted and recreated.

I've checked and it is considered valid API so we'll look to get it added to the models. When asking about it I was told it should be treated as an opaque string and whilst the value will be different for a recreated database you should not rely on the represented time.

If you wouldn't mind sharing I'm curious to learn more about your use case for the field. Have you written a replicator using this library?

tgujrathi commented 1 month ago

Thank you for your prompt response.

We have a specific scenario where we used to have a non-partitioned database for time series data. We have now transitioned to a new partitioned database. To determine the switch time and from which database data should be retrieved, we are using the instance_start_time of the partitioned database. The assumption is that time series data where the timestamp is later than instance_start_time is stored in a new partitioned database.

For instance, if a timestamp is provided that is older than the new partitioned database's instance start time, then we have to fetch the data from the old non-partitioned database. Otherwise, if the timestamp is more recent, we should fetch it from the new database. If the timestamp falls in between, we need to retrieve the data from both databases.

rnewson commented 1 month ago

fyi, whether a database is partitioned or not is returned in the response to a GET /$dname request, in the props value. "partitioned":true if partitioned, the field is absent if not.

rnewson commented 1 month ago

and also fyi instance_start_time is not a safe method of detecting database creation time, that's not its intended function even if currently happens to match.

tgujrathi commented 1 month ago

Okay, is there another way to determine the creation time of the database? As we have to determine database switch time.

rnewson commented 1 month ago

yes, record it yourself into a document inside a database.

ricellis commented 1 month ago

FTR we added instanceStartTime to the models in #1533. It will be included in the next release. Note that in line with the other API model property names in this lib it uses the TS convention camel case naming instanceStartTime (not the raw JSON response snake case name).

eiri commented 1 month ago

This should be now restored as instanceStartTime in https://github.com/IBM/cloudant-node-sdk/releases/tag/v0.9.2