Some idea to explore to improve Synql.
For now, Synql uses two tables to register modifications: _synql_log and _synql_fklog.
Synql uses a view to unify its two logs into a single log ()_synql_unified_log).
These two tables could be merged into a single one:
CREATE TABLE _synql_unified_log(
...
field integer NOT NULL,
val any DEFAULT NULL,
foreign_row_ts integer DEFAULT NULL,
foreign_row_peer integer DEFAULT NULL,
...
)val could always be set to NULL for a field that refers to a foreign key.
foreign_row_ts, foreign_row_peer could always be set to NULL for fields that don't refer to foreign keys.
For now Synql relies on the presence of an implicit column named rowid.
This column is the real primary key of a SQLite table.
We could avoid this assumption and use the column marked as primary key.
We can still fallback to rowid if no column is marked as primary key.
Pros:
- This makes the implementation more compatible with other database engines.
- This allows supporting
WITHOUT ROWIDSQLite tables - This avoids some fragility (
rowidvacuum, etc.)
Cons:
- This could make the code more complex.
Remove ts in _synql_local and only use _synql_context.
A new timestamp could be the max value between the max timestamps of the context + 1 and the current unix timestamp. The computation of the maximum of the context could be cheap thanks to https://www.sqlite.org/optoverview.html#minmax.
Pros:
- Reduce redundancy
- Remove a trigger
Cons:
- This could be hard to use during a merge?