Vim-db: Modern database interface for Vim(github.com)
github.com
Vim-db: Modern database interface for Vim
https://github.com/tpope/vim-db
57 comments
Shout out to Tim Pope!
I follow his work since I started using Vim ~ 8 years ago, the absolute pinnacle for me being vim-fugitive, I can't live without it!
I follow his work since I started using Vim ~ 8 years ago, the absolute pinnacle for me being vim-fugitive, I can't live without it!
I don't want to be Debbie Downer, but what's the usecase for this tool that isn't better suited for a client in a separate terminal? I am guessing that the two biggest answers would be the :%DB command and the variable setting, but given the ease of switching and copy-pasting between terminals, this seems superfluous. Maybe it's for easier integration into other plugins?
Personally, if I was looking for a DB integration with VIM, I'd be looking for an interactive prompt style buffer instead of per-command executions.
Personally, if I was looking for a DB integration with VIM, I'd be looking for an interactive prompt style buffer instead of per-command executions.
> I'd be looking for an interactive prompt style buffer instead of per-command executions
> given the ease of switching and copy-pasting between terminals, this seems superfluous.
This really makes me think you are a prime candidate for a plugin that can easily open an interactive prompt or make the whole copy, switch terminal, paste, copy response flow one command.
This is just repl-integration for db repls (interactive prompts if you prefer).
Many people are used to this workflow:
Open your editor, open a prompt in another terminal. Write the simple stuff in the prompt, the complex stuff in your editor and then copy/paste to the prompt. Write a simple query in the prompt that ends up pretty complex, so you copy it, switch to the editor and paste, fix it up then copy, switch to prompt and paste it back. Now you copy part of the query results, switch to editor and paste so you can extract some of the results for the next complicated query.
A lot of us know this workflow, an many of us aren't aware that what we are looking for is repl integration in the editor. Same workflow, goes like this: edit query, eval, edit again, eval, etc. It is not a different way of working, it is the same way but much better.
How do you know if you want this? If you use vim and set your readline config to use vi keybindings you want this. You already noticed that editing stuff in the prompt is worse than in vim, you just picked the wrong fix for that problem.
> given the ease of switching and copy-pasting between terminals, this seems superfluous.
This really makes me think you are a prime candidate for a plugin that can easily open an interactive prompt or make the whole copy, switch terminal, paste, copy response flow one command.
This is just repl-integration for db repls (interactive prompts if you prefer).
Many people are used to this workflow:
Open your editor, open a prompt in another terminal. Write the simple stuff in the prompt, the complex stuff in your editor and then copy/paste to the prompt. Write a simple query in the prompt that ends up pretty complex, so you copy it, switch to the editor and paste, fix it up then copy, switch to prompt and paste it back. Now you copy part of the query results, switch to editor and paste so you can extract some of the results for the next complicated query.
A lot of us know this workflow, an many of us aren't aware that what we are looking for is repl integration in the editor. Same workflow, goes like this: edit query, eval, edit again, eval, etc. It is not a different way of working, it is the same way but much better.
How do you know if you want this? If you use vim and set your readline config to use vi keybindings you want this. You already noticed that editing stuff in the prompt is worse than in vim, you just picked the wrong fix for that problem.
If you use tmux, the transmission of a command from Vim to another tmux pane is remarkably simple. It's just a shell out to the tmux binary with the appropriate arguments.
My problem with vim-integrated shells, prompts - anything inherently interactive except for editing itself - is that it's always worse. Be it performance, integration between vim and the interactive prompt, or an impedance mismatch between vim's modal editing and an interactive prompt's non-modal editing. I'd rather switch windows and use a native shell than a kinda-working shell in vim. Same with a DB prompt. Same with pretty much every other tool I pull up in the terminal.
Honestly, it's the same reason I don't use emacs with EVIL mode: it's not quite vim, and those speedbumps absolutely kill my "Flow". Any gains from a rich editing environment are lost (with interest) by trying to figure out how to get the non-editing part of that environment to behave correctly. And I even use emacs bindings in bash (no, not zsh or fish or...); because then when I go to remote servers, everything just works.
That's my opinion, at least.
My problem with vim-integrated shells, prompts - anything inherently interactive except for editing itself - is that it's always worse. Be it performance, integration between vim and the interactive prompt, or an impedance mismatch between vim's modal editing and an interactive prompt's non-modal editing. I'd rather switch windows and use a native shell than a kinda-working shell in vim. Same with a DB prompt. Same with pretty much every other tool I pull up in the terminal.
Honestly, it's the same reason I don't use emacs with EVIL mode: it's not quite vim, and those speedbumps absolutely kill my "Flow". Any gains from a rich editing environment are lost (with interest) by trying to figure out how to get the non-editing part of that environment to behave correctly. And I even use emacs bindings in bash (no, not zsh or fish or...); because then when I go to remote servers, everything just works.
That's my opinion, at least.
But this plugin is, framed in terms you might be more familiar with, a plugin that wraps the "shell out to the tmux pane then copy the output into the buffer I'm in" step. That's it.
This isn't a vim-integrated shell solution, it's a way to avoid those, for exactly the reasons you say. Repl integration isn't about embedding a prompt in your editor, it's about bypassing the interactive prompt because you already have a place to write and read text - an editor buffer. I should have used a different term obviously, that one is actually misleading.
Part of the reason I'm curious is I regularly do Clojure training and see this pattern over and over: "I don't like working that way, that sounds bad. [hours later it clicks] Oh! I see what you mean, this is great. This is the way I like working but easier! I thought you meant something different".
This isn't a vim-integrated shell solution, it's a way to avoid those, for exactly the reasons you say. Repl integration isn't about embedding a prompt in your editor, it's about bypassing the interactive prompt because you already have a place to write and read text - an editor buffer. I should have used a different term obviously, that one is actually misleading.
Part of the reason I'm curious is I regularly do Clojure training and see this pattern over and over: "I don't like working that way, that sounds bad. [hours later it clicks] Oh! I see what you mean, this is great. This is the way I like working but easier! I thought you meant something different".
True, sorry, was just really wanting to point out how easy such a thing is, then got distracted on a tangent on why I don't want windows embedded in my vim.
For me, vim is so integral now to my dev workflow that being able to work in a single environment is great.
I don't really use and cli tooling for DB access and querying, now being able to use a vim pane as my query entry is really nice - no switching back and forth between various applications.
An interactive prompt would be pretty nice though, agree with that.
I don't really use and cli tooling for DB access and querying, now being able to use a vim pane as my query entry is really nice - no switching back and forth between various applications.
An interactive prompt would be pretty nice though, agree with that.
inb4 "oh so you should use emacs" :D
I find it really amusing that the vim ecosystem is reinventing emacs, more slowly, in a worse language. There are some really amazing, really smart people (like Tim Pope), creating some really amazing, really cool software — I can only imagine how much more effective they'd be if they were working in a better environment.
I’m tied to Windows at work. I’ve tried to start a few conversations about offering MacBooks as an option, but that never goes anywhere due to the additional upfront cost.
Given that constraint, I picked up Vim and have used it for the past 6 years. Tried Emacs at first, but it didn’t play well on Windows (not sure if user error!)
So I definitely encourage “reinventing the wheel” on multiple platforms, as long as the platform is popular enough. Competition doesn’t hurt.
Given that constraint, I picked up Vim and have used it for the past 6 years. Tried Emacs at first, but it didn’t play well on Windows (not sure if user error!)
So I definitely encourage “reinventing the wheel” on multiple platforms, as long as the platform is popular enough. Competition doesn’t hurt.
Modal editing is just that good. ;-)
The thing that would get me to use Emacs is a plugin implementing Neovim's remote editing protocol. Vim is an incredibly deep state machine, and no plugins that reimplement it get things exactly right.
The thing that would get me to use Emacs is a plugin implementing Neovim's remote editing protocol. Vim is an incredibly deep state machine, and no plugins that reimplement it get things exactly right.
You can do remote file editing with local editor setting using Emacs TRAMP which when used with SSH profiles treats remote files as if they were local files.
If you love modal editing, as I do, you can use EVIL mode to emulate Vim quite well. I used Vim for years and switched within a month, most of the transition was in getting used to all the tools built into Emacs. Movement was identical, even things like text objects and Vim-surround work well.
The quality of Emacs packages are very high and almost always “just work”. And when you do have to read the documentation it’s very easy to find and understand.
If you love modal editing, as I do, you can use EVIL mode to emulate Vim quite well. I used Vim for years and switched within a month, most of the transition was in getting used to all the tools built into Emacs. Movement was identical, even things like text objects and Vim-surround work well.
The quality of Emacs packages are very high and almost always “just work”. And when you do have to read the documentation it’s very easy to find and understand.
By "remote editing protocol," I meant the Neovim RPC API which allows other editors or tools to run a Neovim server and get it's exact behavior, keystroke for keystroke. It's been a few years since I tried EVIL, but last time I ran into behavior differences within fifteen minutes (something about pane management? It's been a while). I don't want "almost exactly Vim," I want, "literally identical to Vim," as a starting point.
Sublime Text has a plugin which implements the API; it runs full blown vim plugins.
Sublime Text has a plugin which implements the API; it runs full blown vim plugins.
>Sublime Text has a plugin which implements the API; it runs full blown vim plugins.
.. .. I didn't realize the integration was that far along. I'll have to give Sublime another look.
.. .. I didn't realize the integration was that far along. I'll have to give Sublime another look.
I hear good things about evil-mode & viper for emacs. Dunno about Neovim's remote editing protocol though. TRAMP does the trick exceedingly well for me (to include 'remote' editing as root on the local machine, which is kinda awesome).
I have tried evil mode many times. It just doesn't work. It may be 99% faithful implementation of vim but I hit the missing 1% so often that I throw up my hands before quitting out to use the real thing.
Which parts of EVIL mode don’t work as you expect them to?
99% of ex commands don't work.
Isn't it the same use case as having say SQL Server Management Studio? You get nice syntax highlighting and your Vim dev environment for modifying SQL then you can run the script and see the result and edit, rinse, repeat
I can do exactly what you mention with two terminal windows, swapping back and forth with a single key combination. As a bonus, it lets me take advantage of keeping my connection credentials out of a history file.
My response is based largely on my workflow - I use VIM as one part of my development environment (ie the shell), not as a standalone IDE. Perhaps this is the biggest difference.
My response is based largely on my workflow - I use VIM as one part of my development environment (ie the shell), not as a standalone IDE. Perhaps this is the biggest difference.
As I got better over with Vim I wanted more and more things under the editing and movement power of Vim Text Objects -
https://blog.carbonfive.com/2011/10/17/vim-text-objects-the-...
That's probably why I ended up with Emacs/Evil mode :)
https://www.emacswiki.org/emacs/SqlMode
For me SQL is editing and sending chunks of text fluently, that exactly where vim or emacs are at their best.
https://blog.carbonfive.com/2011/10/17/vim-text-objects-the-...
That's probably why I ended up with Emacs/Evil mode :)
https://www.emacswiki.org/emacs/SqlMode
For me SQL is editing and sending chunks of text fluently, that exactly where vim or emacs are at their best.
I agree a powerful text editor is essential for me to write SQl code. I use Sublime Text as my Postgres Editor (easy with it’s build tool) ST3 is in a different league to flaky clunky slow PGadmin or Postico or SQLPro or Navicat etc (I’ve ried them all).
Beautiful Themes Postgres specific plugin for SQL highlighting, amazing text find & replace & manipulation, instant feedback, all the power of PSQL but in a much nicer environment, lightning speed, never crashes even if you bring back a few millions rows.
Yeah, the best implementation of vi is written in Emacs Lisp
That sounds like someone who never fully committed to Vim. Yes, Evil is excellent. I've mostly switched to using Emacs because of it, and Org-mode.
But I still can't quite get past the feeling that Emacs is a clunky sedan and Vim is a sleek sports car. Vim just feels a little bit nicer, faster, smoother.
But I still can't quite get past the feeling that Emacs is a clunky sedan and Vim is a sleek sports car. Vim just feels a little bit nicer, faster, smoother.
I was all in on vim for about ten years and then, when I started getting into Common Lisp, I would use emacs from time to time because slime is better than the vim equivalents and I eventually realized (a) evil-mode is an amazingly faithful implementation of a fairly comprehensive portion of vim’s features and (b) that you could program emacs in a language that wasn’t pathological.
I'm with you, but it isn't hard for me to remember when I didn't realize that's what I wanted and was really really good at the whole tmux/copy-pasting between terminal windows dance.
I think you need to see a screencast to understand why this approach is such an improvement, for some reason it is hard to grasp at first.
I think you need to see a screencast to understand why this approach is such an improvement, for some reason it is hard to grasp at first.
I use tmux for this, often with a horizontal split displaying the output of the script on the bottom and the query/ddl on top (just like isqlw).
I know it's possible to automate further (to make vim talk to tmux and execute the bit of SQL under the cursor, for example), but it works well for me as is.
I know it's possible to automate further (to make vim talk to tmux and execute the bit of SQL under the cursor, for example), but it works well for me as is.
> Personally, if I was looking for a DB integration with VIM, I'd be looking for an interactive prompt style buffer instead of per-command executions.
Especially when "modern" is in the title, one might expect more than just a wrapper of :DB commands. Given that both Vim 8 and Neovim have a :terminal, this might as well be a collection of shell functions; it'd also be more portable.
Especially when "modern" is in the title, one might expect more than just a wrapper of :DB commands. Given that both Vim 8 and Neovim have a :terminal, this might as well be a collection of shell functions; it'd also be more portable.
having a consistent interface between local and terminal is ideal. being able to highlight any text in any buffer and say 'send this to DB and place results in new pane' is extremely usable. You dont see this sort of power in things like intellij or visual studio because it normally requires you to open an entirely different program for sql.
Having a single active connection is an assumption those tools tend not to make
Have you ever used dbext?
I dont understand your comment because it can handle multiple connections. Connections are referred to as named profiles. If you want to work with one connection at a time for safety sake you can use :DBSetOption profile=X
But dbext is vimscript which is very hackable like anything else in vim. If you want to use multiple connections theres nothing stopping you from writing something like
nmap <leader>se1 to run the selection with connection profile #1
nmap <leader>se2 to run the selection with connection profile #2
and so forth
But dbext is vimscript which is very hackable like anything else in vim. If you want to use multiple connections theres nothing stopping you from writing something like
nmap <leader>se1 to run the selection with connection profile #1
nmap <leader>se2 to run the selection with connection profile #2
and so forth
Either you're not using vim right or I don't know how to copy and paste correctly. and
Everyone should probably be paying Tim Pope some sort of tribute for all the software that has been written more quickly because of his plugins. Companies working on other editors should be trying to recruit him!
Shameless self-promotion incoming, but if you're mostly using postgres (like me), you can take a look at https://github.com/martingms/vipsql as well.
Nice work! I use (a slightly modified version of) https://github.com/ivalkeen/vim-simpledb
Looks pretty similar to yours. I definitely like that model of editing / execution.
Looks pretty similar to yours. I definitely like that model of editing / execution.
I see Tim Pope, I upvote. This guy has produced some of the plugins that have changed how I Vim forever (vim-surround, pathogen, vim-repeat, vim-fugitive, etc.)
I'd love to see a screencast. I'm mostly an emacser but I like vi ergonomics very much, and would love to see the approach here.
This is a very nascent project but started by one of the best vim developers around, Tim Pope. As someone who has run into some of the rougher edges from time to time of dbext I applaud this effort and will closely watch progression
SQlite support. awesome.
Not integrated in vim, but try visidata (https://github.com/saulpw/visidata) on Sqlite. I tried after HN post last weekend and it was amazing... with Vim-like keys and interface.
Is it hard at all to exit vim-db?
It's a pity it doesn't support Oracle.
Some corps force developers to use it.
It says right in the list of supported DBs "Your own easily implemented adapter" - it's definitely something that can be added.
Odds are he built it to use the DBs he uses, now it's your turn to contribute back the adapter for the DB you use.
Odds are he built it to use the DBs he uses, now it's your turn to contribute back the adapter for the DB you use.
When Oracle is forced, often Java is forced right along with it... Java means most will be using some sort of IDE instead of Vim (not always, but often) But I agree... if we're stuck using that beast of a database, it'd be nice to see support in my tooling.
Looking at the code there's some thought of allowing both SQL Server and Oracle.
He only just released it today so there's time to add the others.
He only just released it today so there's time to add the others.
So make the case for Postgres and show the business how much cash they will save. Don’t submit to your fate, fight it.
In my experience, the organization is well aware how much they need to switch away from Oracle. They're reminded every billing period. By then it's just no small feat.
Look at Amazon, aggressively trying to move away from Oracle yet still far away.
Look at Amazon, aggressively trying to move away from Oracle yet still far away.
Is there any overlap in Oracle and Mac usage?
Where I work most of the developers use Mac and are stuck with a legacy oracle db.
https://github.com/tpope?tab=repositories