Chris, whilst I'm sure you could work something out, it probably wouldn't generally work as database connections contain a lot of state, such whether or not we're in a transaction and variables.
On 8 March 2017 at 20:23, Chris Foresman <fores...@gmail.com> wrote: > I'll chime in to say I've had a similar problem related to the shell and I > couldn't sort out how to address it. > > Our database servers will drop connections that last longer than 10 > minutes. So basically can never do a task I might otherwise use the shell > for that would take longer than 10 minutes of typing things in the shell. > The workaround I eventually arrived at was copying all the data I pulled > from previous runs into a doc in my text editor, and restart the shell > every time the database connection dropped. Eventually I was able to just > copy and paste enough stuff from that doc to get everything done in the 10 > minute limit. Is there a way (e.g. the DatabaseWrapper mentioned above) to > get the shell to reconnect without stopping the shell and restarting from > scratch every time? > > On Tuesday, March 7, 2017 at 7:30:27 AM UTC-6, James Pic wrote: >> >> It seems like we have 2 kind of issues: >> >> - code broke runserver, >> - network broke runserver. >> >> In the first case, runserver waits for a code reload event which is >> perfect ;) >> In the second case, runserver also waits for a code reload event, which >> is not very intuitive after fixing a network error. >> >> So if we want to handle both case, we indeed need to detect if an error >> is caused by code or networking, which is defined by CACHES, DATABASES and >> CHANNEL_LAYERS. >> >> Perhaps we could add a special attribute to the exception, so >> DatabaseWrapper.get_new_connection()'s call of: >> >> connection = Database.connect(**conn_params) >> >> Would become something like: >> >> try: >> connection = Database.connect(**conn_params) >> except Exception as e: >> e.network_error = True >> raise >> >> Another way would be to inspect exc info or have a pre-defined list of >> exceptions that are to be considered as network error, which involves >> referencing to exceptions potentially defined by other packages such as >> redis. >> >> While that may seem a lot for runserver, I've restrained myself from >> talking about what this could look like in production so far in the >> discussion, but I feel like even production deployment could somehow >> benefit from this at some point, so that might be worth the effort after >> all. >> > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/django-developers/cc47bf21-9bbd-4728-9f2f- > 968405d128ad%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/cc47bf21-9bbd-4728-9f2f-968405d128ad%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Adam -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM0kFw%3Dr5ZvS-h7548dGSX1XgGEYweZOqS2XrRn%3DpdrD6Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
