A better example might be a field that must be unique, like a URL slug. Suppose you have a database of products and the product table has a field used for URLs, like “/tshirt” and “/sweater”. You need those to be unique within the table.
The question remains - how does Marmot enforce a uniqueness constraint? If you don’t like the product example, fine, but it is easy to think of others. It would be unfortunate if marmot is incapable of supporting uniqueness.
As I understand it, transactions are still serialized for any given table, just not across tables. Wouldn’t that solve this uniqueness constraint issue?
People do all sorts of weird things with databases, and if you want to run existing software against a database (as opposed to greenfield development deliberately targeting Marmot) you need to understand what will happen in different cases.
> if you want to run existing software against a database (as opposed to greenfield development deliberately targeting Marmot) you need to understand what will happen in different cases.
A great point, but from the readme in the Marmot repo:
> It does not require any changes to your existing SQLite application logic for reading/writing.
I suspect you’re probably still right, but that’s not what the author claims.
The question remains - how does Marmot enforce a uniqueness constraint? If you don’t like the product example, fine, but it is easy to think of others. It would be unfortunate if marmot is incapable of supporting uniqueness.