remove `change.plugin_key`

[samuelstroschein]

Context

change.plugin_key has been added to identify the "schema" that has been used for the stored changes. However, if someone changes a plugin to another one but both operate on the same schema, using the plugin_key would to query changes would lead to no results.

    const plugin = args.source.plugins.find(
            (p) => p.key === change.plugin_key,
        );

Proposal

Query the change schema via the schema_key proposed in LIX-104.

• querying changes becomes independent of the plugin key
• thus, changing plugins doesn't break change queries

[samuelstroschein]

Yes, right move. See LIXDK-153. All that matters for changes is "what change is stored here?" Any change is identifiable by the schema. A schema can include a plugin namespace like opral-csv-cell and samuel-csv-cell.

  CREATE TABLE change (
    id TEXT PRIMARY KEY DEFAULT (uuid_v4()),
    author TEXT,
    parent_id TEXT,
-    type TEXT NOT NULL,
    file_id TEXT NOT NULL,
-    plugin_key TEXT NOT NULL,
+   schema_key: 
    operation TEXT NOT NULL,
    value TEXT,
    meta TEXT,
    commit_id TEXT,
    created_at TEXT DEFAULT CURRENT_TIMESTAMP NOT NULL
  ) strict;

A thing to consider is whether schemas lix encounters (via plugins for example) are stored in a table ChangeSchema to increase reliability. Ideally, any change that has been stored in lix will always point to a schema that lix can refer to. Even if the plugin that initially defined the schema has been removed. Plus, we can ensure that schema's are unique for the lix.

const plugin: LixPlugin = {
  key: "my-cool-plugin", 
  schemas: {
     "cool-csv-cell": JSONSchema
  }
}

CREATE table change_schema (
  key: TEXT PRIMARY KEY
  schema: JSONSchema
)

  CREATE TABLE change (
   schema_key: TEXT NOT NULL
+  FOREIGN KEY (schema_key) REFERENCES change_schema(key)
    ...
  ) strict;