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
At the moment the various implementations of database drivers and the database client cache the information about the schema used by the database, and therefore if another client, or something else, changes the schema, or cleanups/initializes the database, the client doesn't notice that. Right now that is a problem mostly for the command-line tool tests. They have both a Client object, and invoke the tools which make the schema modifications at the same time. Therefore they can't notice the changes made by the tools with their Client object. The Cloud Functions have this problem too, and need to be stopped for a database upgrade, but that's generally unavoidable in case of backwards-incompatible changes, as those are non-atomic.
Consider adding an interface to refresh/reinitialize/recreate the client on request, so that any schema changes are picked up without having to explicitly recreate the client from potentially locally-unavailable parameters.
The text was updated successfully, but these errors were encountered:
Sure! You've actually implemented one step towards this already - storing the "database" string in the client (even though that is still to be merged).
Sure! You've actually implemented one step towards this already - storing the "database" string in the client (even though that is still to be merged).
can the interphase be something like this @spbnick
def refresh(self):
"""
refresh recreates the client on request
:return:
"""
return Client(self.database)
Yeah, something like that. Only perhaps call it reset, as it would basically amount to discarding the existing driver instance behind the client, and creating a new one using the same "database" string, not actually "refreshing" some data from somewhere, in the sense of e.g. a browser page refresh. We do refresh the information on which schema the database is using, but to do that we destroy and recreate the driver. I.e. we would reset in order to do a refresh, so let's call it what it is: reset.
At the moment the various implementations of database drivers and the database client cache the information about the schema used by the database, and therefore if another client, or something else, changes the schema, or cleanups/initializes the database, the client doesn't notice that. Right now that is a problem mostly for the command-line tool tests. They have both a Client object, and invoke the tools which make the schema modifications at the same time. Therefore they can't notice the changes made by the tools with their Client object. The Cloud Functions have this problem too, and need to be stopped for a database upgrade, but that's generally unavoidable in case of backwards-incompatible changes, as those are non-atomic.
Consider adding an interface to refresh/reinitialize/recreate the client on request, so that any schema changes are picked up without having to explicitly recreate the client from potentially locally-unavailable parameters.
The text was updated successfully, but these errors were encountered: