starred/shiori

Fork 0

mirror of https://github.com/go-shiori/shiori.git synced 2026-04-25 06:25:54 +03:00

[GH-ISSUE #473] First start creates an empty database with no tables #286

New issue

Closed

opened 2026-02-25 23:33:52 +03:00 by kerem · 11 comments

kerem commented

2026-02-25 23:33:52 +03:00

Owner

Originally created by @Katarn on GitHub (Aug 23, 2022).
Original GitHub issue: https://github.com/go-shiori/shiori/issues/473

Originally assigned to: @fmartingr on GitHub.

I run:

./shiori --portable serve

And I see a zero size file shiori.db in the shiori-data directory:

ls -l shiori-data
-rw-r--r-- 1 user users 0 aug 23 21:57 shiori.db

Open in browser, try to login shiori/gopher and see:

failed to fetch accounts: SQL logic error: no such table: account (1) (500)

It works only if before the first start run:

./shiori --portable migrate

I use shiori v1.5.3.

Originally created by @Katarn on GitHub (Aug 23, 2022). Original GitHub issue: https://github.com/go-shiori/shiori/issues/473 Originally assigned to: @fmartingr on GitHub. I run: ```bash ./shiori --portable serve ``` And I see a zero size file `shiori.db` in the `shiori-data` directory: ```bash ls -l shiori-data -rw-r--r-- 1 user users 0 aug 23 21:57 shiori.db ``` Open in browser, try to login `shiori`/`gopher` and see: ``` failed to fetch accounts: SQL logic error: no such table: account (1) (500) ``` It works only if before the first start run: ```bash ./shiori --portable migrate ``` I use shiori v1.5.3.

kerem

2026-02-25 23:33:52 +03:00

closed this issue
added the
component:backend

type:ux

priority:high

database
labels

kerem commented

2026-02-25 23:33:52 +03:00

Author

Owner

@Katarn commented on GitHub (Aug 24, 2022):

I found a description of this problem in the FAQ, but, IMHO, this is not user friendly. Perhaps it would be better if the application created the database itself?

@Katarn commented on GitHub (Aug 24, 2022): I found a description of this problem in the [FAQ](https://github.com/go-shiori/shiori/blob/master/docs/Usage.md#running-migrations), but, IMHO, this is not user friendly. Perhaps it would be better if the application created the database itself?

kerem commented

2026-02-25 23:33:52 +03:00

Author

Owner

@fmartingr commented on GitHub (Oct 12, 2022):

Hey @Katarn, please take a look at #512

@fmartingr commented on GitHub (Oct 12, 2022): Hey @Katarn, please take a look at #512

kerem commented

2026-02-25 23:33:52 +03:00

Author

Owner

@Katarn commented on GitHub (Oct 13, 2022):

@fmartingr Hello. But it still seems non-obvious to the end user. It seems to me. What is the purpose of migration if the previous version of the database does not yet exist?

@Katarn commented on GitHub (Oct 13, 2022): @fmartingr Hello. But it still seems non-obvious to the end user. It seems to me. What is the purpose of migration if the previous version of the database does not yet exist?

kerem commented

2026-02-25 23:33:52 +03:00

Author

Owner

@hulb commented on GitHub (Oct 14, 2022):

I think auto-migration is complicated and it's comon to initialize database schema in first migration.

@hulb commented on GitHub (Oct 14, 2022): I think auto-migration is complicated and it's comon to initialize database schema in first migration.

kerem commented

2026-02-25 23:33:52 +03:00

Author

Owner

@tetafro commented on GitHub (Oct 14, 2022):

At least it should be added to the installation docs.

(But personally I agree, that making automatically is better.)

@tetafro commented on GitHub (Oct 14, 2022): At least it should be added to the installation docs. (But personally I agree, that making automatically is better.)

kerem commented

2026-02-25 23:33:53 +03:00

Author

Owner

@hulb commented on GitHub (Oct 14, 2022):

At least it should be added to the installation docs.

yeah, it would be more friendly for users.

@hulb commented on GitHub (Oct 14, 2022): > At least it should be added to the installation docs. yeah, it would be more friendly for users.

kerem commented

2026-02-25 23:33:53 +03:00

Author

Owner

@fmartingr commented on GitHub (Oct 14, 2022):

@fmartingr Hello. But it still seems non-obvious to the end user. It seems to me. What is the purpose of migration if the previous version of the database does not yet exist?

That only applies for SQLite, since for Mysql and PSQL you need to provide a database first, but the fact that the actual file in the filesystem does not exist for SQLite equals to a database being empty in Mysql/PSQL. The problem with not running the migration first is that the CLI will create the database file empty, since it expects a database there it will just create it. Maybe we could add an error since we are expecting a database file and telling the user to migrate? But how we will replicate this for the other engines? Should we give an error too if the user has not migrated to the latest schema?

I'm unsure about this, for me, having to migrate schemas is the 101 for backend services, but maybe I'm focusing too much on the engineer side and not on a less tech-savvy user side?

The other problem I see with automatic migrations is that we have very little tests at the moment, and if I ever do something like that I want to have assurances that we don't break things between releases.

And, just because there wasn't enough complexity here, there's the thing that we have three types of users: 1) the ones who use the webui (and the extension), 2) the ones who use the CLI, 3) the ones who use both. I would understand the CLI users to expect things to work magically, but not so much from the service users.

Please, provide your feedback for this, as I don't want to create unnecessary friction for the users.

At least it should be added to the installation docs.

Yeah, documentation needs a bit of love. I would gladly accepts PRs for this! :)

@fmartingr commented on GitHub (Oct 14, 2022): > @fmartingr Hello. But it still seems non-obvious to the end user. It seems to me. What is the purpose of migration if the previous version of the database does not yet exist? That only applies for SQLite, since for Mysql and PSQL you need to provide a database first, but the fact that the actual file in the filesystem does not exist for SQLite equals to a database being empty in Mysql/PSQL. The problem with not running the migration first is that the CLI will create the database file empty, since it expects a database there it will just create it. Maybe we could add an error since we are expecting a database file and telling the user to migrate? But how we will replicate this for the other engines? Should we give an error too if the user has not migrated to the latest schema? I'm unsure about this, for me, having to migrate schemas is the 101 for backend services, but maybe I'm focusing too much on the engineer side and not on a less tech-savvy user side? The other problem I see with automatic migrations is that we have very little tests at the moment, and if I ever do something like that I want to have assurances that we don't break things between releases. And, just because there wasn't enough complexity here, there's the thing that we have three types of users: 1) the ones who use the webui (and the extension), 2) the ones who use the CLI, 3) the ones who use both. I would understand the CLI users to expect things to work magically, but not so much from the service users. Please, provide your feedback for this, as I don't want to create unnecessary friction for the users. > At least it should be added to the installation docs. Yeah, documentation needs a bit of love. I would gladly accepts PRs for this! :)

kerem commented

2026-02-25 23:33:53 +03:00

Author

Owner

@Katarn commented on GitHub (Oct 16, 2022):

@fmartingr It seems obvious to me that if the SQLite database file does not exist or is zero size, the application should migrate automatically and then connect to it as usual.

The reason I'm considering the behavior for SQLite separately from other database engines is that when a user selects a SQLite, they mean that they want to start working right now without setting up a back-end database. As if it were a usual user-end application. As a rule, he does not know what migration is, and he is not interested in it - this is a programmer's term. He may not understand databases at all as such.

In any case, from my point of view, using one binary (thanks Go) in conjunction with the SQLite makes the application so easy to use that housewives can use it. And the understanding of migration is already the next levels of computer skills.

@Katarn commented on GitHub (Oct 16, 2022): @fmartingr It seems obvious to me that if the SQLite database file does not exist or is zero size, the application should migrate automatically and then connect to it as usual. The reason I'm considering the behavior for SQLite separately from other database engines is that when a user selects a SQLite, they mean that they want to start working right now without setting up a back-end database. As if it were a usual user-end application. As a rule, he does not know what migration is, and he is not interested in it - this is a programmer's term. He may not understand databases at all as such. In any case, from my point of view, using one binary (thanks Go) in conjunction with the SQLite makes the application so easy to use that housewives can use it. And the understanding of migration is already the next levels of computer skills.

kerem commented

2026-02-25 23:33:53 +03:00

Author

Owner

@fmartingr commented on GitHub (Oct 28, 2022):

hey mean that they want to start working right now without setting up a back-end database.

You are totally right on that. I mostly focus on the server side of the spectrum where migrations are a common thing, but it's true that when using CLI users shouldn't require this kind of knowledge and/or steps. I will give this a thought but I may probably either revert the migration changes or just make a --no-migrate flag for users that want to tackle that on their own (though once you have something automatic that need is pretty unlikely).

Don't expect this change soon ™️ , as I've just started on a new position and I'm fairly busy with that and other things, but if any of you want to tackle this I will try to keep PRs checked every few days so I don't have a huge backlog of things to do once I have some "free" time 🙃

@fmartingr commented on GitHub (Oct 28, 2022): > hey mean that they want to start working right now without setting up a back-end database. You are totally right on that. I mostly focus on the server side of the spectrum where migrations are a common thing, but it's true that when using CLI users shouldn't require this kind of knowledge and/or steps. I will give this a thought but I may probably either revert the migration changes or just make a `--no-migrate` flag for users that want to tackle that on their own (though once you have something automatic that need is pretty unlikely). Don't expect this change soon ™️ , as I've just started on a new position and I'm fairly busy with that and other things, but if any of you want to tackle this I will try to keep PRs checked every few days so I don't have a huge backlog of things to do once I have some "free" time 🙃

kerem commented

2026-02-25 23:33:53 +03:00

Author

Owner

@Katarn commented on GitHub (Oct 28, 2022):

It's great that we finally understand each other. Unfortunately, I don't know Go at all, so I can't help much.

Good luck in your new position!

@Katarn commented on GitHub (Oct 28, 2022): It's great that we finally understand each other. Unfortunately, I don't know Go at all, so I can't help much. Good luck in your new position!

kerem commented

2026-02-25 23:33:53 +03:00

Author

Owner

@sergeevabc commented on GitHub (Nov 13, 2022):

@Katarn, thank you for brining this up. Shiori's first-time use is so messed up.

@sergeevabc commented on GitHub (Nov 13, 2022): @Katarn, thank you for brining this up. Shiori's first-time use is so messed up. ![image](https://user-images.githubusercontent.com/373718/201512550-5e043cad-8016-43fb-b414-3164b4a50838.png)