ChartDB to simplify database design and visualization, providing a powerful, intuitive tool that’s fully open-source. This database diagram tool is similar to traditional ones you can find: dbeaver, dbdiagram, drawsql, etc.
So my first impression is that the requirement to copy-paste that elaborate SQL to get the schema is clever but not sufficiently intuitive. Rather than saying “Run this query and paste the output”, you say “Run this script in your database” and print out a bunch of text that is not a query at all but a one-liner Bash script that relies on the existence of pbcopy – something that (a) doesn’t exist on many default installs (b) is a red flag for something that’s meant to be self-hosted (why am I talking to a pasteboard?), and (c) is totally unnecessary anyway.
Instead, you could just say: “Run this query and paste the result in this box” and print out the raw SQL only. Leave it up to the user to figure out how they want to run it.
Alternatively you can also do something like: “Run this on your machine and copy/paste the output”:
In the case of the cloud service, it’s also not clear if the data is being stored on the server or client side in LocalStorage. I would think that the latter would be preferable.
Thanks for the thoughtful feedback, Daniel! You bring up a great point about the complexity of the current approach with the SQL script and the reliance on pbcopy. We’ll definitely consider simplifying it by providing just the raw SQL query, so users can run it in whatever way works best for them. As for the cloud version, we’re leaning towards using LocalStorage for data storage on the client side to keep everything local to the user’s machine, ensuring privacy and control. We’ll make this clearer in the UI and documentation. Appreciate the suggestions - they’re super helpful as we continue refining ChartDB!
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !selfhosted@lemmy.world
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.
Rules:
Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
Resources:
selfh.st Newsletter and index of selfhosted software and apps
So my first impression is that the requirement to copy-paste that elaborate SQL to get the schema is clever but not sufficiently intuitive. Rather than saying “Run this query and paste the output”, you say “Run this script in your database” and print out a bunch of text that is not a query at all but a one-liner Bash script that relies on the existence of
pbcopy– something that (a) doesn’t exist on many default installs (b) is a red flag for something that’s meant to be self-hosted (why am I talking to a pasteboard?), and (c) is totally unnecessary anyway.Instead, you could just say: “Run this query and paste the result in this box” and print out the raw SQL only. Leave it up to the user to figure out how they want to run it.
Alternatively you can also do something like: “Run this on your machine and copy/paste the output”:
In the case of the cloud service, it’s also not clear if the data is being stored on the server or client side in
LocalStorage. I would think that the latter would be preferable.Thanks for the thoughtful feedback, Daniel! You bring up a great point about the complexity of the current approach with the SQL script and the reliance on pbcopy. We’ll definitely consider simplifying it by providing just the raw SQL query, so users can run it in whatever way works best for them. As for the cloud version, we’re leaning towards using LocalStorage for data storage on the client side to keep everything local to the user’s machine, ensuring privacy and control. We’ll make this clearer in the UI and documentation. Appreciate the suggestions - they’re super helpful as we continue refining ChartDB!