You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Database states are immutable in Blaze. That is even true in case we delete history during permanent removal of resources (#399), because history is part of the immutable database state. Deleting the history of a resource means that a new database state is constructed which will no longer contain the history of that resource.
Database states are used for all query operations like FHIR Search and CQL evaluation. The immutability of database states ensures full consistency of those operations without the need for transactions or locking. As such database states are needed as long as they are used by a query operation but can be discarded afterwards. Because FHIR Search uses paging to deliver the query results to the client in consumable chunks and the client itself is responsible to request the next page, Blaze can't know how long a database state has to be kept alive. Currently database states will never expire.
However because in case the history of a resource is deleted for GDPR compliance reasons, the resources should not be accessible through former database states. So database states have to expire after a reasonable amount of time. That amount of time has to allow for paging of FHIR Search results and for longer running CQL evaluations. For now I would suggest to set the expiration duration fix to 30 days because erasure without undue delay should be carried out in one month. Later if requested, we can make this duration configurable with a sensible minimum to not break query operations immediately.
Paging URL's should return a 404 Not Found in case the database state they like to access is expired. That will be implemented in #1995.
The text was updated successfully, but these errors were encountered:
Database states are immutable in Blaze. That is even true in case we delete history during permanent removal of resources (#399), because history is part of the immutable database state. Deleting the history of a resource means that a new database state is constructed which will no longer contain the history of that resource.
Database states are used for all query operations like FHIR Search and CQL evaluation. The immutability of database states ensures full consistency of those operations without the need for transactions or locking. As such database states are needed as long as they are used by a query operation but can be discarded afterwards. Because FHIR Search uses paging to deliver the query results to the client in consumable chunks and the client itself is responsible to request the next page, Blaze can't know how long a database state has to be kept alive. Currently database states will never expire.
However because in case the history of a resource is deleted for GDPR compliance reasons, the resources should not be accessible through former database states. So database states have to expire after a reasonable amount of time. That amount of time has to allow for paging of FHIR Search results and for longer running CQL evaluations. For now I would suggest to set the expiration duration fix to 30 days because erasure without undue delay should be carried out in one month. Later if requested, we can make this duration configurable with a sensible minimum to not break query operations immediately.
Paging URL's should return a 404 Not Found in case the database state they like to access is expired. That will be implemented in #1995.
The text was updated successfully, but these errors were encountered: