Not OP, but I personally put off using a UI for years before finally trying a few and eventually settling on Postico for Mac. I still jump to psql often, but for me it's an accumulation of small quality-of-life improvements:
- results are formatted nicely by default; no more doing a first query, getting too many columns so results wrap unreadably, then changing the columns for a second query, and so on
- manually editing rows is as easy as with a spreadsheet; of course hopefully you don't have to do this often...
- I can change common filters & sorts in the UI with a few clicks instead of having to change SQL; sure, the SQL would only require typing a few characters, but if it's 2 clicks vs. 8 characters, it's still a small win
Downsides are:
- the GUI has an interface for saving queries, but it refuses to let me save them to a subfolder of my project; it wants to save them all in some global location. This doesn't seem good for sharing queries
- if you are doing more complicated sorting or aggregation, it's still easier to just go to psql than to fiddle with the GUI
a big one for me is being able to jump between/search for tables and preview their rows, columns, and indexes quickly; especially when there are many tables/schemas and i don't remember their names
another one is a more comfortable editing experience for queries
Looking forward to trying it, though would be nice if credentials could be specified in a different way than on the command line (whereby they'll get saved into your command line history).
Generally if you put a space before your command it'll bypass the history, though depending on your *nix you might need to set `HISTCONTROL=ignoreboth` in your bashrc or similar if it's not already.
Agree that it would be nice to specify credentials a different way - however as a workaround: some bash-based shells support prefixing the command with a space as a way of not saving that command into history.
`psql` allows for putting your credentials in a dotfile with a very simple syntax. Should be quick to add support for, and would create a seamless onboarding experience for people who are already using `psql`.
I only looked at the linked file, so I'm not going to speak to the rest of the code and don't really have a good grasp of the architecture here.
This seems mostly ok. The only thing that (imo) wouldn't pass code review is that big honking loop at https://github.com/achristmascarl/rainfrog/blob/main/src/app.... That thing needs to be refactored down to be readable, with individual logic chunks being put into their own functions and tidied up a bit.
That's not really Rust-specific, obviously, but all the `match` and `if let` and whatever other Rust stuff looks fine, so it's what I've got.
on a more serious note, the library i used for the query editor, tui-textarea [0], is very well done, and the other db tui i drew inspiration from, gobang[1], is a great example of a ratatui app. would recommend checking those out
I really like this, and I think others will too. Please be judicious with feature requests - so far the simplicity and ease of use is what I like most about it!
popups are windows. selecting+copying text from the results-table does not work the first time. clicking in the left pane on a connection sometimes picks the wrong one (really weird this one as it is not consistent). i only see the standard wayland icon (not the worst).
Sorry for the dumb question, but what is the significance of this issue, "popups are windows"? Has something changed in Wayland which makes child windows unworkable?
Why dumb? Just a question to me, I gladly elaborate.
If I loose a connection I used to get a little popup in the bottom right corner when I try to execute a query, explaining why it's not executing.
They now popup in the middle of the screen and are much larger. I remember I had to close them by hand at some point, but maybe I'm wrong because I just reproduced it and they closed themselves quickly.
Only this little popups annoy me. The bigger child windows behave the same.
(The 2-3 child windows that show on app startup --flash, tip-of-the-day, and another one-- are quite annoying though and according to my colleagues it's not possible to enforce a setting that stop them from showing; but these were already annoying on Xorg)
Ah, I understand - this is happening as part of Apples' crusade to rid the world of popup menus. Thanks for the details - I encounter little fiddly issues like this with my own apps, so its good context.
Just to confirm - this happens with the older version of DBeaver, running on the newer version of MacOS, right? You didn't upgrade DBeaver, meanwhile, I assume?
Charm/bubbletea toolstack, is very much focused on an ELM style architecture, I.e. message passing and deriving UI from state. You can still do immediate type UI if that is what you prefer, but it won't fit with any of the standard components. Bubbletea is a framework more or less, so even if you know Go, it will require you to learn how to build to its strengths.
Ratatui is by default not very opinionated about how to handle state and updates, which requires some development from you, or using a third party library to get an opinionated architecture around it. Ratatui is more of a collection of libraries, out of the box, it expects a certain interface for components, but it is up to you how you want to compose them together. Whether that is immediate-, stateful-, react-, or ELM style. Stateful is the default for all their examples.
Charms way of doing terminal UI is very much based around strings, which can sometimes give issues with spacing, as components can be fiddly to be constrained within a certain space.
Ratatui creates UI on top of a matrix of bytes, which makes it more difficult to do easy things, but allows you to more easily build complex uis.
Generally I prefer Ratatui, as you can really build robust and fast uis on top of it. It does take a bit more work to get started though. I am also biased by Rust tho.
Ratatui maintainer here. I'd agree with all of the above points.
The lack of opinionated approach stems from Ratatui being not a framework, but a library (you call us, we don't call you), and not having any of the event/input handling things included.
There's likely room for a framework or two on top of it.
What would you say are the key benefits of using this over psql? Is it mainly table metadata and properties?
Asking because running queries, history, formatting of results etc. can be achieved by configuring psqlrc.
Not OP, but I personally put off using a UI for years before finally trying a few and eventually settling on Postico for Mac. I still jump to psql often, but for me it's an accumulation of small quality-of-life improvements:
- results are formatted nicely by default; no more doing a first query, getting too many columns so results wrap unreadably, then changing the columns for a second query, and so on
- manually editing rows is as easy as with a spreadsheet; of course hopefully you don't have to do this often...
- I can change common filters & sorts in the UI with a few clicks instead of having to change SQL; sure, the SQL would only require typing a few characters, but if it's 2 clicks vs. 8 characters, it's still a small win
Downsides are:
- the GUI has an interface for saving queries, but it refuses to let me save them to a subfolder of my project; it wants to save them all in some global location. This doesn't seem good for sharing queries
- if you are doing more complicated sorting or aggregation, it's still easier to just go to psql than to fiddle with the GUI
For results formatting, line selection, etc simply installing pspg as your psql pager helps a lot.
oh wow, if i had known about pspg beforehand i might not have made this, it looks great!
would symlinks in that global location help, maybe?
It’s a good idea! For some reason Postico’s built-in query viewer doesn’t seem to follow them, unfortunately.
a big one for me is being able to jump between/search for tables and preview their rows, columns, and indexes quickly; especially when there are many tables/schemas and i don't remember their names
another one is a more comfortable editing experience for queries
I didn’t learn this until recently but in psql you can use \e or \editor to open the current line in $EDITOR. It helps a lot.
Here's a trick for running this against a Heroku PostgreSQL database (here for a Heroku app called "simonwillisonblog"):
Looks pretty cool. I could see this being useful for some of my coworkers. I might try it with read-only access.
I pretty much always use DataGrip or pgcli and don't see that changing, but will keep an eye on this.
Yeah. Reminds me of k9s.
Lazydocker too. I'm not affiliated, just in love
Nice work! Would be cool to have a plugin system that could allow for interfacing with other DBs like sqlite etc.
thank you! support for other DBs is planned, starting with mysql and sqlite. no set timeline yet though
Nice! I see DBeaver and DataGrip implementing connection layer through JDBC.
Not sure if that would be a viable option in Rust.
Looking forward to trying it, though would be nice if credentials could be specified in a different way than on the command line (whereby they'll get saved into your command line history).
Generally if you put a space before your command it'll bypass the history, though depending on your *nix you might need to set `HISTCONTROL=ignoreboth` in your bashrc or similar if it's not already.
Agree that it would be nice to specify credentials a different way - however as a workaround: some bash-based shells support prefixing the command with a space as a way of not saving that command into history.
Ref: https://www.gnu.org/software/bash/manual/html_node/Bash-Vari...
`psql` allows for putting your credentials in a dotfile with a very simple syntax. Should be quick to add support for, and would create a seamless onboarding experience for people who are already using `psql`.
that makes sense, thank you for opening an issue!
I'm new to Rust, can someone tell me if that's good Rust code I could learn from?
https://github.com/achristmascarl/rainfrog/blob/main/src/app...
I only looked at the linked file, so I'm not going to speak to the rest of the code and don't really have a good grasp of the architecture here.
This seems mostly ok. The only thing that (imo) wouldn't pass code review is that big honking loop at https://github.com/achristmascarl/rainfrog/blob/main/src/app.... That thing needs to be refactored down to be readable, with individual logic chunks being put into their own functions and tidied up a bit.
That's not really Rust-specific, obviously, but all the `match` and `if let` and whatever other Rust stuff looks fine, so it's what I've got.
nope :)
on a more serious note, the library i used for the query editor, tui-textarea [0], is very well done, and the other db tui i drew inspiration from, gobang[1], is a great example of a ratatui app. would recommend checking those out
[0] https://github.com/rhysd/tui-textarea
[1] https://github.com/TaKO8Ki/gobang
Looks great! I'll be watching your progress with great interest.
What do you use for the DataTable widget? Is there a Rust/Ratatui equivalent of DataTable (https://textual.textualize.io/widgets/data_table/) used by Harlequin?
yep! ratatui has the Table widget: https://docs.rs/ratatui/latest/ratatui/widgets/struct.Table....
(People downvoting this: that's the author.)
I really like this, and I think others will too. Please be judicious with feature requests - so far the simplicity and ease of use is what I like most about it!
thank you! and noted :)
Looks sleek! But I’m curious, what made you decide that gobang[0] wasn’t cutting it for you?
[0] https://github.com/TaKO8Ki/gobang
There are a bunch of these, like [1] and [2], probably a lot more.
--
1: https://harlequin.sh/
2: https://www.pgcli.com/
Gobang seems stagnated (no PRs merged since last year), which is a shame.
main reason was that it hadn't been updated in a while. i also wanted the query editor to be more flexible / not limited to just filtering
since Wayland there are some issues with DBeaver; this project seems like a great way out!
What are some of the issues?
popups are windows. selecting+copying text from the results-table does not work the first time. clicking in the left pane on a connection sometimes picks the wrong one (really weird this one as it is not consistent). i only see the standard wayland icon (not the worst).
Sorry for the dumb question, but what is the significance of this issue, "popups are windows"? Has something changed in Wayland which makes child windows unworkable?
Why dumb? Just a question to me, I gladly elaborate.
If I loose a connection I used to get a little popup in the bottom right corner when I try to execute a query, explaining why it's not executing.
They now popup in the middle of the screen and are much larger. I remember I had to close them by hand at some point, but maybe I'm wrong because I just reproduced it and they closed themselves quickly.
Only this little popups annoy me. The bigger child windows behave the same.
(The 2-3 child windows that show on app startup --flash, tip-of-the-day, and another one-- are quite annoying though and according to my colleagues it's not possible to enforce a setting that stop them from showing; but these were already annoying on Xorg)
Ah, I understand - this is happening as part of Apples' crusade to rid the world of popup menus. Thanks for the details - I encounter little fiddly issues like this with my own apps, so its good context.
Just to confirm - this happens with the older version of DBeaver, running on the newer version of MacOS, right? You didn't upgrade DBeaver, meanwhile, I assume?
This looks excellent, with one potential caveat: does it support slash commands (e.g. \dt)?
it does not unfortunately; open to suggestions about common slash commands ppl would like to see included as shortcuts!
All of them would be great, but if not, the most common ones IME are:
And the variants (e.g. \dti+)Been seeing lots of cool TUIs built with ratatui. Can anyone offer a comparison between ratatui and Golang https://github.com/charmbracelet/bubbletea?
I've been wanting to get into building a TUI but can't decide which library to pick.
I've been using both.
Charm/bubbletea toolstack, is very much focused on an ELM style architecture, I.e. message passing and deriving UI from state. You can still do immediate type UI if that is what you prefer, but it won't fit with any of the standard components. Bubbletea is a framework more or less, so even if you know Go, it will require you to learn how to build to its strengths.
Ratatui is by default not very opinionated about how to handle state and updates, which requires some development from you, or using a third party library to get an opinionated architecture around it. Ratatui is more of a collection of libraries, out of the box, it expects a certain interface for components, but it is up to you how you want to compose them together. Whether that is immediate-, stateful-, react-, or ELM style. Stateful is the default for all their examples.
Charms way of doing terminal UI is very much based around strings, which can sometimes give issues with spacing, as components can be fiddly to be constrained within a certain space.
Ratatui creates UI on top of a matrix of bytes, which makes it more difficult to do easy things, but allows you to more easily build complex uis.
Generally I prefer Ratatui, as you can really build robust and fast uis on top of it. It does take a bit more work to get started though. I am also biased by Rust tho.
Ratatui maintainer here. I'd agree with all of the above points.
The lack of opinionated approach stems from Ratatui being not a framework, but a library (you call us, we don't call you), and not having any of the event/input handling things included.
There's likely room for a framework or two on top of it.
I second this, could some also add C#'s "Spectre.Console" https://github.com/spectreconsole/spectre.console
I found it but great in handling interactivity compared to https://github.com/gui-cs/Terminal.Gui