CREATE TABLE "JSON_document" (
id VARCHAR(64) NOT NULL,
access_token VARCHAR(255),
json_string TEXT,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
updated_at DATETIME,
PRIMARY KEY (id)
);
CREATE TABLE "JSON_document" (
id VARCHAR(255) NOT NULL,
access_token VARCHAR(255),
unlisted BOOLEAN,
is_json_ld BOOLEAN,
json_string TEXT,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
updated_at DATETIME,
PRIMARY KEY (id),
CHECK (unlisted IN (0, 1)),
CHECK (is_json_ld IN (0, 1))
);
- unlisted — could just be set to false because there will be no Activity Stream I guess
- is_json_ld — could just be set to false for the same reason
- length of ID column
- access_token — the new JSONkeeper requires a prefix in front of the access_token[1]
[1] the old JSONkeeper just stores Firebase UIDs or X-Access-Tokens as is. To prevent collisions between to two types the new JSONkeeper adds prefixes frbs:
and free:
respectively. For exampe, instead of storing the Firebase UID gAo6iXt85qdWCZyCV3Dp8yxQH3R3
, it would save it as frbs:gAo6iXt85qdWCZyCV3Dp8yxQH3R3
and instead of storing the freely chosen X-Access-Token foo
would save it as free:foo
.
I would assume that the X-Access-Token (since their is no client that uses it and therefore has to be given "manually" — e.g. when posting with curl) was only used by myself for tests. For a simple solution I would therefore suggest to just add the prefix frbs:
to all access_token entries when migrating.