Storm could usefully support readonly Stores

[Richard Boulton]

In a mutithreaded environment using SQLite, it can be useful to have a policy that only one Store at a time may ever be written to, to avoid getting "deadlocks" (which are eventually resolved by a timeout leading to a "database is locked" exception).

When implementing such a policy, it would be useful to be able to mark any store which isn't intended to be written to as readonly, to avoid coding errors. Such a store would raise an exception (probably a ProgrammingError) whenever an attempt to change the data in the database was made (eg, by adding a document, changing a property in an object retrieved from the database, or by executing some SQL which changes the database directly). Marking stores readonly in such a way would mean that an accidental coding error would result in a repeatable ProgrammingError, rather than an occasional (ie, thread execution order dependent) OperationalError("database is locked"). It could also help lead to clearer code.

To get a readonly store, a "readonly=1" option would be added to the URI used to open the database - all stores derived from that database would then be readonly.

[Stuart Bishop (stub)]

I have a similar use case where I have read-only slave PostgreSQL databases.

At the moment, we are using a customized storm.databases.postgres.Postgres that issues a SET DEFAULT_TRANSACTION_READ_ONLY TO TRUE on connection.

ZStorm can make use of this too. No need to commit a Store with a read-only Database (or a read-only Store), just rollback instead and no need to get involved in two phase commit.

So for Launchpad, I probably will not be able to use such a feature soon (We will need to be able to create and modify temporary tables on the slave databases, despite all the persistent data being read-only). But it is worth making this feature available to all backends rather than a SQLite only extension switched on via the connection URI.