Bringing back Coda 2 Integrated Database editor/manager to life, or APIs for Devs to do so?

Feature Requests
1

Hi :wave:

Coda 2 used to have a beautiful database editor (I’m not sure if it was limited to MySQL only), which is dearly missed!

I understand, of course, that things have changed dramatically since then, and there are many DB services. It may not be possible to maintain such a feature, so a Language Server Protocol (LSP) approach is needed to allow the community to add the support.

Now, I’m not very experienced in this subject matter, but I’ve been forced to use VSCode :weary: because I’m programming in Java against my will :weary:. There is no Java LSP extension in Nova just yet. I was messing with databases and came across the SQLTools Extension. I found it quite interesting and intriguing. I’m not sure about the inner workings, but it seems like a nice approach where users can add drivers as they need, and voila, you would have a fully-fledged database viewer and editor. As an extension, it’s pretty impressive. In fact, the first thing that came to my mind was the Coda 2 nostalgia, haha.

It would be extremely handy if Panic designed some sort of native, built-in SQLTool, and then developers could create extensions based on that, etc. :innocent:

1 Like
2

Have you try tableplus? A dedicated tool is probably the best way you can go, the same goes for love, is probably better to concentrate on being the best editor possible

1 Like
3

Mmm, for me personally, being a good editor is all about the ecosystem and superb, efficient, and performant APIs.

In terms of goodness, the fact that Panic migrated to tree-sitter and is incredibly native, they have already ticked all the boxes. It’s the collection of many small things it has that has kept me hooked.

For example, if I only wanted an editor, I could have easily patched Nova and opted for Neovim or Zed, as they are already tree-sitter based, super fast with a low footprint, or heck, even good old Vim (I’m sure we all have that one friend who codes in vi with zero syntax highlighting and completions :joy:).

To put it this way, you could argue that for Nova’s Git support or anything else at this point, why bother when you can have a dedicated app like Git-Tower? But to be frank, I just hate the idea of opening a lot of apps, switching back and forth just to perform a “simple task.” I dislike it so much that I mainly work in psql in Nova’s built-in terminal rather than using pgAdmin, Beekeeper, or TablePlus (which is undoubtedly best in class).

For instance, ever since Nova 11, I’ve barely opened my dedicated git app or CLI. Don’t get me wrong; they will always have their uses, especially for complicated tasks. But for simple tasks like table viewing, examining domain structures in the relation, or having a scratchpad for sending quick, dirty SQL commands with dynamic auto-completion based on the opened DB, I think Nova can do it even better than SQLTools in VSCode!

4

That’s a looong comment Emran :grinning: remember this is just my humble opinion

I understand when you say opening more apps sucks, I also feel that nova’s GIT implementation is great, but I still feel that the editor has some missing features like auto rename closing tag, compare files and some little things, which I believe are more important than the DB feature, if I’m not mistaken a long time ago they ask on twitter if people really used the DB feature and the winner was no (I voted yes)

I never used a DB plug-in in VScode but I did notice every time I added a plug-in it made it a little slower, maybe is just me, but I do prefer a cleaner nova

Anyway, TablePlus is an excellent app that also does SQLite and a few more, some features are excellent, I was hesitant at first, coming from sequel pro and Ace, but it’s definitely worth the change

5

I agree. I would love Nova to have a built-in database editor.

The whole point of an Integrated Development Environment is for the tools to be “integrated.” Yes, a standalone editor is more capable, but the same could be said of a dozen features that are part of Nova or any other I.D.E.

I have yet to find a database editor for macOS that is both reliable, and not complete overkill for day-to-day work.

Sequel Ace is pretty close to good, but it’s not reliable. On my M2 machine, it crashes at least once a day.

Every other tool I’ve found is a subscription, crippled by feature bloat, or both. Not everyone is a data scientist working with data lakes or rivers or glaciers. Some of us are just building web sites, and need to update a few things along the way.

6

I think that’s the problem. They chose to use a sample size of “people currently active on Twitter who just happen to get selected by Twitter’s algo to see this poll” rather than “people trying to do work” which is a much bigger, more diverse set of users and potential customers.

7

I’ve never once wished Nova had a db editor, and I’d imagine it’d slow down Nova dev pretty significantly to reinvent the wheel and provide in-app DB management.

8

To echo somewhat: we didn’t just poll Twitter, we also took customer feedback during Nova’s pre-beta development period in 2018 as we A/B tested a lot of aspects of it, and the response from the majority of the Coda 2 users who participated was that very few did actually rely on the MySQL integration (albeit the few that did expressed as much, and we weighed it in our decisions). The same feedback is what solidified our decision not to reimplement Subversion support alongside Git.

I totally understand that for developers who rely on heavy SQL database work day-to-day it’d be a wonderful addition, however as Bryan says, adding something akin to Coda 2’s support back would be a massive undertaking for us. The foundation used for it in Coda 2 was pretty much literally the Sequel Pro codebase wrapped up into a framework (and from what I remember, Sequel Ace was forked from the same codebase after Sequel Pro stopped being actively developed.)

The other major aspect of it that drove our decision in 2018/2019 was that Sequel Pro’s codebase at the time really only worked with MySQL databases. As adoption of Postgres was advancing to meet or surpass MySQL as the most used RDBM a rapid pace at the time, as well as the widespread adoption of SQLite for smaller applications, retrofitting the codebase to support either was going to be a huge undertaking for our team, which wasn’t something we could reasonably approach (especially consider we didn’t develop that particular codebase in the first place, adding another barrier of entry, as it were.)

Approaching such a feature again today would likely mean either finding a different codebase we could work with and tightly integrate into Nova which does support Postgres (and maybe SQLite) in addition to MySQL, which introduces a whole host of licensing questions (we had a mutual agreement of some kind with the Sequel Pro folks for Coda 2 since it was a commercial app like Nova, IIRC), or instead developing a new codebase from scratch. To be honest, neither of these are particularly likely.

Developing a new codebase is especially unlikely, because (as many know) our development team at Panic is small (our apps engineering team is effectively four people total for Nova, Transmit, and Prompt) and we are already fully occupied with our current development milestones laid out over probably the next few years (barring anything of supreme importance coming along, we roughly know what big things we’ll be working on next, and after that, and after that, etc.). It’s just a matter of budgeting time and person power.

I know this really isn’t what some folks want to hear, but unfortunately it’s just sort of the truth of the matter. The feature wasn’t used much by the overall community, so we can’t justify developing it again and then maintaining that support going forward. It’s always something we can re-evaluate as time goes by, like here in this discussion. But for now, nothing regarding it has changed.

1 Like