migrate placeholer dataSources to providerConnectionRequests#188
migrate placeholer dataSources to providerConnectionRequests#188ewollesen wants to merge 1 commit into
Conversation
|
The migration that leads to this change: https://github.com/tidepool-org/tools-private/pull/97 |
eecac75 to
726c978
Compare
| $ref: ./providerId.v1.yaml | ||
| x-stoplight: | ||
| id: ej94kmuykpg1k | ||
| expirationTime: |
There was a problem hiding this comment.
I wonder if we need a "firstConnectedTime" here as well. This would be set when the device is successfully connected for the first time.
You can tell if the device is connected by the existence of a matching data source in the connected state, but you wouldn't know if previous connection requests were ever successful or not.
For example, if a patient had three dexcom connection requests, you couldn't know if the two earliest requests were ever successfully connected or not.
It seems useful to know that, but I don't know that we need to know that. It's not clear that any decision would be made based on knowing that information.
There was a problem hiding this comment.
Hmm, not sure. We can always derive firstConnectedTime from the createdTime of the data source itself. If we want to know that a connection was made after a connection request was made, then I'd probably add that here as just connectedTime. That way you could walk back through the connection requests for the provider and "see" somewhat of a history. There are some edge cases we'd need to consider though. (What if a connection was made not using an outstanding invite? What if that connection was made after the expiration?)
| $ref: ./providerId.v1.yaml | ||
| x-stoplight: | ||
| id: ej94kmuykpg1k | ||
| expirationTime: |
There was a problem hiding this comment.
Hmm, not sure. We can always derive firstConnectedTime from the createdTime of the data source itself. If we want to know that a connection was made after a connection request was made, then I'd probably add that here as just connectedTime. That way you could walk back through the connection requests for the provider and "see" somewhat of a history. There are some edge cases we'd need to consider though. (What if a connection was made not using an outstanding invite? What if that connection was made after the expiration?)
726c978 to
fd92b7d
Compare
The expirationTime property of dataSources is moved to providerConnectionRequests. The dataSource states of pending and pendingReconnect are no longer valid. They can instead be identified like so: - pending: a (non-expired) providerConnectionRequest exists for provider X, but no dataSource for that provider exists. - pendingReconnect: a (non-expired) providerConnectionRequest exists for provider X, and there's also a dataSource for that provider, whose state isn't "connected". BACK-4414
fd92b7d to
1fc450f
Compare
|
Squashed down to a single commit, and rebased onto latest master. |
3 participants
The expirationTime property of dataSources is moved to providerConnectionRequests. The dataSource states of pending and pendingReconnect are no longer valid. They can instead be identified like so:
pending: a (non-expired) providerConnectionRequest exists for provider X, but no dataSource for that provider exists.
pendingReconnect: a (non-expired) providerConnectionRequest exists for provider X, and there's also a dataSource for that provider, whose state isn't "connected".
BACK-4414