Closed ThallesP closed 9 months ago
Nice work, @ThallesP. I like that you met the requirement for easy management by including the SQLite web interface.
I did find some minor issues to sort out.
Mainly, the entrypoint file isn't successfully executing all logic:
Running database init ./entrypoint.sh: line 18: shasum: not found Running database init ./entrypoint.sh: line 25: can't open init_db.sql: no such file
Looks like you just need to COPY it into the container.
Also, even if you sort the issue with shasum
, I don't think the logic to handle checking the hash of the init file is going to work to run only if changed, since the hash is hardcoded and you're not updating it.. unless I'm misunderstanding your intent. I feel like you can toss that logic and make it so that the init_db.sql
only runs on initial deployment. I like the idea of allowing people to manage their schema and data from that file, over multiple deployments, but I feel like it adds unnecessary complexity to the entrypoint script. Open to hearing your thought process of course!
Lastly, could you please also add a sample schema in the init_db.sql
? It doesn't have to be complex at all, maybe just a CREATE TABLE IF NOT EXISTS $TABLE_NAME
with a few different columns, and insert a few lines of sample data into the table?
Nice work, @ThallesP. I like that you met the requirement for easy management by including the SQLite web interface.
I did find some minor issues to sort out.
Mainly, the entrypoint file isn't successfully executing all logic:
Running database init ./entrypoint.sh: line 18: shasum: not found Running database init ./entrypoint.sh: line 25: can't open init_db.sql: no such file
Looks like you just need to COPY it into the container.
Also, even if you sort the issue with
shasum
, I don't think the logic to handle checking the hash of the init file is going to work to run only if changed, since the hash is hardcoded and you're not updating it.. unless I'm misunderstanding your intent. I feel like you can toss that logic and make it so that theinit_db.sql
only runs on initial deployment. I like the idea of allowing people to manage their schema and data from that file, over multiple deployments, but I feel like it adds unnecessary complexity to the entrypoint script. Open to hearing your thought process of course!Lastly, could you please also add a sample schema in the
init_db.sql
? It doesn't have to be complex at all, maybe just aCREATE TABLE IF NOT EXISTS $TABLE_NAME
with a few different columns, and insert a few lines of sample data into the table?
Thanks, i'll sort out the entrypoint issue.
Regarding the hash, the intention was to execute it only when the user specifically wants to. This is due to the fact that if the user opts to deploy the template via the Railway dashboard, the deployment occurs automatically, and the repository is created along with it. As a result, there is no window of time available for the user to make modifications to that file before the deployment takes place.
I can probably separate that in a seed_db.sql
file that does the above and the init_db.sql
will include the sample data. What do you think?
For sure! I like the idea of enabling users to add data to the db from within a file in the repo, so I do appreciate the effort you put in to adding this. It feels like asking a lot of you to add more logic to account for two files and all that. I think just making it straightforward so that init_db.sql
is run when the container is deployed from the template, which creates a table or two and seeds some sample data is plenty to get people going. Then you could eliminate the logic looking at the hash and everything altogether.
That said, if you are enjoying the thought exercise, I won't tell you not to do the extra work to set up a seed mechanism :) I think people may find it useful if they don't have a frontend or just want a way to bulk insert data. If you want a quicker dialog, let me know and we can chat on Discord
For sure! I like the idea of enabling users to add data to the db from within a file in the repo, so I do appreciate the effort you put in to adding this. It feels like asking a lot of you to add more logic to account for two files and all that. I think just making it straightforward so that
init_db.sql
is run when the container is deployed from the template, which creates a table or two and seeds some sample data is plenty to get people going. Then you could eliminate the logic looking at the hash and everything altogether.That said, if you are enjoying the thought exercise, I won't tell you not to do the extra work to set up a seed mechanism :) I think people may find it useful if they don't have a frontend or just want a way to bulk insert data. If you want a quicker dialog, let me know and we can chat on Discord
Hi, just implemented that.
Here's a link: https://sqlite3-production-08ef.up.railway.app/ Password: 3h5piei9kpx-4$9u
hope that im not billed that much for the preview :pray:
@ThallesP beautiful!! I deployed it from scratch and then seeded some more data. It's as easy as can be, I think. Also I love the trains table haha
I have created this repo and invited you as a maintainer: https://github.com/railwayapp-templates/sqlite
Could you push your code to this repo then update the Template config to point there? After that, please shoot me an email at melissa@railway.app, and we'll start the payout process.
PS let me know if you need some credits on your account. Would love to see you submit some more stuff!
Contact Details
contato@thalles.me
Template URL
https://railway.app/template/jOiNFt
What does this template deploy?
Solves #419
It deploys SQLite database with WebUI (https://github.com/coleifer/sqlite-web) for easy management. It also has the support for
init_db.sql
.Demo project
No response