After reading through Tom’s reply on the Django Forums, I had an idea that the problem might be in how the connection object itself is initialized, not the sqlite3 connection. Reading through the codebase confirmed my suspicion, and, in hindsight, I should’ve thought of this from the start.
Since I was manipulating the sqlite3 connection.connection database directly, the new database lacked important django-specific initializers which led to failures related to pre-defined django sqlite3 functions that are created during initialization, transaction failures, and other similar failures. Adding in connection.connect() removed failures related to incorrect initialization.
import sqlite3
sourcedb = sqlite3.connect('%s.sqlite3' % str(alias))
settings_dict = connection.settings_dict
settings_dict['NAME'] = 'file:memorydb_{}_{}?mode=memory&cache=shared'.format(str(alias), str(_worker_id))
connection.settings_dict.update(settings_dict)
connection.connect()
sourcedb.backup(connection.connection)
However, it was important to note that the database NAME couldn’t be ‘:memory:’ or ‘file:memorydb{}{}?mode=memory&cache=shared’. Having the database name as either option leads to errors due to name conflicts with the alias database. Each in-memory database must have a unique URI name to be correctly identified.
With the implementation of the above only three thankfully consistent SQLite failures remain- which is a much more sane proposition.
All in all, it feels like the project is almost done with SQLite.
I will have to take a break for the next two weeks though to take time for my exams and studies. I’ll resume work around the second-third week of June and start testing PostgreSQL and MySQL. I’ve tried to finish as much work as I can by starting early from May 17th. Hopefully, I won’t be too far behind when it comes to PostgreSQL and MySQL.