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
If I leave botany running for too long (possibly while other users run it, or also leave it running), eventually a "database is locked" error invades the screen.
Sorry that it wasn't possibly to copy paste the full trace well (the output mangled with botany's usual output), but that I captured provides the relevant parts:
self.run()
File "/usr/lib/python3.9/threading.py", line 892, in run
File "/ self._target(*self._args, **self._kwargs) _bootstrap_inner
File "/home/repos/botany/botany.py", line 434, in autosave
self.update_garden_db(this_plant)
File "/home/repos/botany/botany.py", line 517, in update_garden_db
self.init_database()
File "/home/repos/botany/botany.py", line 491, in init_database
c.execute(init_table_string)
sqlite3.OperationalError: database is locked
I could provide a patch to catch the error on init_database's execute, but before that it probably makes sense to decide what to do in these cases: while ignoring the failure is probably alright on autosave calls (the next autosave deals with it; we can also create a counter of consecutive fails to make sure it is only a sporadic concurrency issue), it probably is not in other calls. Also, it make sense investigating the root cause of the issue - who/what is locking the database for so long?
The text was updated successfully, but these errors were encountered:
If I leave botany running for too long (possibly while other users run it, or also leave it running), eventually a "database is locked" error invades the screen.
Sorry that it wasn't possibly to copy paste the full trace well (the output mangled with botany's usual output), but that I captured provides the relevant parts:
I could provide a patch to catch the error on init_database's execute, but before that it probably makes sense to decide what to do in these cases: while ignoring the failure is probably alright on autosave calls (the next autosave deals with it; we can also create a counter of consecutive fails to make sure it is only a sporadic concurrency issue), it probably is not in other calls. Also, it make sense investigating the root cause of the issue - who/what is locking the database for so long?
The text was updated successfully, but these errors were encountered: