Implement support for multiple persistence stores. about topic-db HOT 4 CLOSED

Quite surprisingly (from my point of view), the most asked for database has been SQLite.

If I were to use it at scale, I would certainly go for a PostgreSQL setup, but if I were to set it up for someone on a shared hosting (which I would never like to do) then MySQL would perhaps be the most ubiquitous relational database. However, for a toy project or for a quick debugging something like zero-setup file-based database such as SQLite becomes the excellent choice. It is also great for application that need to be portable (e.g., in a self-contained mobile application). SQLite is very good at removing the getting started friction off and serves as a good default in situations where we want batteries included, but replaceable. Adding an ORM layer would frees the application up from rigid dependency on a specific database system and would accommodate well with changing landscape of coll kids' storage preferences.

This reminds me of a couple of almost a decade old short ad videos:

• https://www.youtube.com/watch?v=Ir6IdIIZS7c
• https://www.youtube.com/watch?v=YkfAmiSQ948

from topic-db.

Migrated the topic map engine to PostgreSQL (with no intention of supporting multiple persistence stores, anymore).

from topic-db.

Several people have asked for a different database back-end other than PostgreSQL. Quite surprisingly (from my point of view), the most asked for database has been SQLite. It should be relatively simple to implement support for multiple back-ends using the strategy pattern. Although I do expect to have to refactor a couple of store methods it should not be too much work.

from topic-db.

Self-hosting is the way forward for Contextualise. Hence, migrated TopicDB to SQLite.

from topic-db.