Hello! We've been using this client in a Django application environment for quite some time now and several times we've had the issue that the connection was lost and we had to login again. This shouldn't happen as there is an automatic refresh token but the Exact help desk did not know what could be the cause of this issue.
Now I read in your latest release that this IniStorage which is used by default might be the cause of this issue.
We have a Django web application but also several management commands and Celery tasks which all use this client using the same storage.
Your suggestion is to create a custom storage and that it's really easy to do and indeed, the example in exactonline.storage.base looks easy but how can we implement a self.fetch_stuff_from_somewhere(...) which is then threadsafe and won't cause this issue?
Am I correct in assuming that the [transient] settings (access_token, refresh_token, etc.) which are now stored in the ini should actually be unique per thread or application in our case?
My first thought was to keep the [transient] settings in memory (as properties on the storage object itself) while the other settings could be read from a persistent storage. This way the Django application will get its own transient settings and the Celery tasks will create their own personal storage each time they are run.
Do you have any suggestions on how to implement a storage like this?
Are there any downsides of creating a ExactApi instance with a "fresh" storage (without any of the transient settings) each time? Some tasks could be doing this several times an hour.
Have you ever implemented something like this yourself which could serve as an example?
I hope you can point me in the right direction!
Kind regards
Hello! We've been using this client in a Django application environment for quite some time now and several times we've had the issue that the connection was lost and we had to login again. This shouldn't happen as there is an automatic refresh token but the Exact help desk did not know what could be the cause of this issue.
Now I read in your latest release that this IniStorage which is used by default might be the cause of this issue.
We have a Django web application but also several management commands and Celery tasks which all use this client using the same storage.
Your suggestion is to create a custom storage and that it's really easy to do and indeed, the example in
exactonline.storage.baselooks easy but how can we implement aself.fetch_stuff_from_somewhere(...)which is then threadsafe and won't cause this issue?Am I correct in assuming that the
[transient]settings (access_token,refresh_token, etc.) which are now stored in the ini should actually be unique per thread or application in our case?My first thought was to keep the
[transient]settings in memory (as properties on the storage object itself) while the other settings could be read from a persistent storage. This way the Django application will get its own transient settings and the Celery tasks will create their own personal storage each time they are run.Do you have any suggestions on how to implement a storage like this?
Are there any downsides of creating a
ExactApiinstance with a "fresh" storage (without any of the transient settings) each time? Some tasks could be doing this several times an hour.Have you ever implemented something like this yourself which could serve as an example?
I hope you can point me in the right direction!
Kind regards