Add support for ecto_sqlite3_extras

[orsinium]

I've created ecto_sqlite3_extras, a package designed specifically to show stats for SQLite3 databases in Phoenix Live Dashboard. This PR integrates the package with the live dashboard. I mimicked the API and implementation of ecto_psql_extras (and ecto_mysql_extras did the same), so the integration was quite straightforward.

Moving forward, some code and documentation can be cleaned up a bit. It was ok to copy-paste the same text twice but not that ok when you do it 3 times, and maybe more in the future. However, for now, I decided not to be creative and do the same as what ecto_mysql_extras team did.

[orsinium]

The tests require PostgreSQL database with a specific username and password, but I don't see docker-compose or similar. Is there a simple way to run tests locally?

[alexcastano]

Hi @orsinium!

Thanks for your PR. I miss the configuration in the file dev.exs that allows us to try the dashboard in development mode. Right now, we can give two arguments --postgres and --mysql. It would be nice to have the same for sqlite3.

A docker compose for the databases to be used in dev and test environments would be interesting too. For example, I execute the following command for MySQL:

docker run --restart=unless-stopped --name mariadb -e MARIADB_ALLOW_EMPTY_ROOT_PASSWORD=yes -e MARIADB_DATABASE=phx_dashboard_test -p 3306:3306 -d mariadb:latest

[orsinium]

Thank you for the review! All good comments, I'll make sure to fix it all. I also want to provide some more tests, similar to what we have to MySQL. I'll ping you when it's done.

[alexcastano]

Hi @orsinium ,

Thanks again for your job. I will review it again when I have more time, but I see this error when clicking on Sequence number:

[orsinium]

but I see this error when clicking on Sequence number:

Yep, I know. The issue is on the library side, and I don't know yet how to resolve it:
https://github.com/orsinium-labs/ecto_sqlite3_extras/blob/master/lib/queries/sequence_number.ex#L19-L21

Suggestions are welcome. People usually solve it by creating and then dropping a temporary table with an autoincrement column, but I'd like to have all queries read-only.

[mindreframer]

@orsinium It seems this is the only way:

https://renenyffenegger.ch/notes/development/databases/SQLite/internals/schema-objects/sqlite_sequence

The structure of sqlite_sequence can be displayed with the SQLite shell command .schema sqlite_sequence. Because sqlite_sequence is only created when the first table with an autoincrement column exists, we first need to create such a table.

One can not create this table up-front:

sqlite> CREATE TABLE IF NOT EXISTS sqlite_sequence(name,seq);
Run Time: real 0.000 user 0.000060 sys 0.000060
Parse error: object name reserved for internal use: sqlite_sequence

So the best way would be to use a migration to create a dummy table + drop it, as you have already mentioned.

create table dummy (id integer primary key autoincrement);
drop table dummy; 
SELECT name AS table_name, seq AS sequence_number FROM sqlite_sequence ORDER BY sequence_number DESC;

Maybe it is possible to have an init callback with the repo, and then one could create this table on demand:

SELECT name FROM sqlite_master WHERE type='table' AND name='sqlite_sequence';

Also: SQLite queries are fast, so performance wont be a concern here. I would suggest to get it done in a non-clean way, just to get it done. And if there is a better, cleaner way, improve it later.

Thanks for the ecto_sqlite3_extras-package, looks nice!

[alexcastano]

but I see this error when clicking on Sequence number:

Yep, I know. The issue is on the library side, and I don't know yet how to resolve it: https://github.com/orsinium-labs/ecto_sqlite3_extras/blob/master/lib/queries/sequence_number.ex#L19-L21

Suggestions are welcome. People usually solve it by creating and then dropping a temporary table with an autoincrement column, but I'd like to have all queries read-only.

I don't use SQLite, but could you capture this specific error to return an empty result? I think the library shouldn't create any table; it can cause problems in future versions. The way should be to capture the no table exception and return an empty result.

[orsinium]

Fixed! Thank you all for your help :)

[alexcastano]

🎉 🎉 🎉 🎉 🎉

[orsinium]

Thank you all! ❤️