Creating a lookaside table for primary keys ends up making triggers rather complex since they must either update or consult this lookaside in multiple places and we are not able to store variables in triggers.
In other words, we have a bunch of
INSERT OR IGNORE INTO lookaside (...);
SELECT (SELECT key FROM lookaside WHERE ...), ...
The update trigger also installs more than one trigger for update in order to handle primary key changes since changing a primary key is an update + delete.
Triggers do not run in a deterministic order in SQLite so each trigger would need to write the lookaside.
To try to simplify all this, I'm moving everything into a function so triggers will become:
CREATE TRIGER foo AFTER INSERT ON bar BEGIN
SELECT crsql_after_update('table', new_primary_keys, old_primary_keys, new_columns, old_columns);
END;
and crsql_after_update will do all the correct thing.
293
344
Creating a lookaside table for primary keys ends up making triggers rather complex since they must either update or consult this lookaside in multiple places and we are not able to store variables in triggers.
In other words, we have a bunch of
The
updatetrigger also installs more than one trigger for update in order to handle primary key changes since changing a primary key is an update + delete.Triggers do not run in a deterministic order in SQLite so each trigger would need to write the lookaside.
To try to simplify all this, I'm moving everything into a function so triggers will become:
and
crsql_after_updatewill do all the correct thing.