schema_version exists, but Miniflux tries to run migration

[BerkhanBerkdemir]

Hello,

I have migrated my Miniflux 2.0.36 instance of off managed PostgreSQL. I guess I successfully ran pg_restore without errors. Then I modified /etc/miniflux.conf and I set DATABASE_URL as a valid URI. However, Miniflux unit did not work properly but reporting this

You must run the SQL migrations, the database schema is not up to date: current=v0, expected=v54

The table returns,

miniflux_production=# SELECT version FROM schema_version;
 version
---------
 54
(1 row)

For future reference, I used following command to restore the PostgreSQL dump

createdb -O miniflux -T template0 miniflux_production
pg_restore --verbose --no-acl --no-owner -h /var/run/postgresql/ -U postgres -d miniflux_production miniflux-production.dump

If I set RUN_MIGRATION=1, then PostgreSQL returns as schema_version exists. I have feeling that this report is related to

v2/database/database.go

Lines 71 to 78 in ab3fdf5

	func IsSchemaUpToDate(db *sql.DB) error {
	var currentVersion int
	db.QueryRow(`SELECT version FROM schema_version`).Scan(&currentVersion)
	if currentVersion < schemaVersion {
	return fmt.Errorf(`the database schema is not up to date: current=v%d expected=v%d`, currentVersion, schemaVersion)
	}
	return nil
	}

I tried to give information what you might need. Please directly ping me when you write a comment.

Thanks for this great project.

[BerkhanBerkdemir]

If this is an installation issue, what should I do? Miniflux can't read the deployed table and assumes that there is nothing to run.

[nikdoof]

Had the same issue, turns out the tables and sequences in the miniflux db were not owned by the user used by miniflux.

Here is the SQL I used to correct the ownership, probably a better/quicker way but it works:

ALTER TABLE public."acme_cache" OWNER TO miniflux;
ALTER TABLE public."api_keys" OWNER TO miniflux;
ALTER TABLE public."categories" OWNER TO miniflux;
ALTER TABLE public."enclosures" OWNER TO miniflux;
ALTER TABLE public."entries" OWNER TO miniflux;
ALTER TABLE public."feed_icons" OWNER TO miniflux;
ALTER TABLE public."feeds" OWNER TO miniflux;
ALTER TABLE public."icons" OWNER TO miniflux;
ALTER TABLE public."integrations" OWNER TO miniflux;
ALTER TABLE public."schema_version" OWNER TO miniflux;
ALTER TABLE public."sessions" OWNER TO miniflux;
ALTER TABLE public."user_sessions" OWNER TO miniflux;
ALTER TABLE public."users" OWNER TO miniflux;
ALTER SEQUENCE public."api_keys_id_seq" OWNER TO miniflux;
ALTER SEQUENCE public."categories_id_seq" OWNER TO miniflux;
ALTER SEQUENCE public."enclosures_id_seq" OWNER TO miniflux;
ALTER SEQUENCE public."entries_id_seq" OWNER TO miniflux;
ALTER SEQUENCE public."feeds_id_seq" OWNER TO miniflux;
ALTER SEQUENCE public."icons_id_seq" OWNER TO miniflux;
ALTER SEQUENCE public."sessions_id_seq" OWNER TO miniflux;
ALTER SEQUENCE public."users_id_seq" OWNER TO miniflux;

[BerkhanBerkdemir]

turns out the tables and sequences in the miniflux db were not owned by the user used by miniflux

I can also confirm that this is because of missing permissions. Do you think that adding operator friendly message will mitigate this issue for not happening in the future?