BobbyWibowo/lolisafe

migrating from chibisafe to lolisafe results in missing columns

jamiew0w opened this issue · 5 comments

hello. i've been testing with migrating from the current version of chibisafe/lolisafe to your fork and after following the steps, it looks like several columns are missing. here's a few examples:

SQLITE_ERROR: table users has no column named timestamp
SQLITE_ERROR: table users has no column named token
[Error: select count(`id`) as `count` from `albums` where (`enabled` = 1 and `userid` = 1) - SQLITE_ERROR: no such column: enabled]
[Error: select `id`, `name`, `original`, `userid`, `size`, `timestamp`, `expirydate`, `albumid` from `files` where (`userid` = 1) order by `id` desc limit 25 - SQLITE_ERROR: no such column: timestamp]
[Error: select count(`id`) as `count` from `albums` where (`enabled` = 1 and `userid` = 1) - SQLITE_ERROR: no such column: enabled]

i can manually make the columns but for ease of mind it'd be good to have docs updated. perhaps the migration was written for when chibisafe was in v3 (it went v4 of march this year).

Thanks again!

Yes, v4 (chibisafe) was a complete rewrite, so no surprises that the database schematics are different (otherwise running the migration script in this fork alone should've been sufficient).
And thanks, that's a fair point, I'll add a notice to the readme soonTM!

thanks for the quick response!

to clarify then, does that mean migrations from v4 aren't currently compatible or do you think manually adding missing colums should fix it? I guess it's hard for you to know but I'll test a bit more over the coming days and see what works and what doesn't.

The inner system is actually fairly simple and straightforward, so only adding the missing columns should make things perform the same as any other installations (look up database/db.js file for the required columns and types).

There are only a few columns where you may be unable to infer their supposed default values, due to the simplicity of SQLite's column types.

For example, for any columns named enabled, they are expected to be of the type integer, but they are actually used for boolean states, so 0 for disabled and 1 for enabled (SQLite does not have boolean type, so had to make do with that).
So after adding the columns, you will also have to fill in 1 as their initial value to actually have them be, well, enabled.

token column in users table is the same as chibisafe's apiKey column, so you'll have to rename that column instead.
editedAt column in users table is the same as chibisafe's apiKeyEditedAt.
No direct equivalent for their passwordEditedAt. My fork's timestamp column stores registration date's timestamp instead.

I can only remember those at the top of my head right now. If you face any other roadblocks, feel free to mention them here and I'll give my inputs if I'm free.

You can probably infer which are which from chibisafe's own v3 to v4 database migration script: https://github.com/WeebDev/chibisafe/blob/abd7a1ca2e058854e6335b54f4119f009961a5ab/src/api/scripts/databaseMigration.js

Just be aware that my fork isn't exactly identical to the original v3, so you will still have to look up my fork's database migration script which adds new columns on top of the original v3: https://github.com/BobbyWibowo/lolisafe/blob/98e6c59255b4aad785282be5c1e443e2fdd5b405/database/migration.js

went ahead with a fresh install instead, wasn't worth all the extra work just for random screenshots. Thanks as always @BobbyWibowo !