Hey thanks for posting this! This is my project I started and the goal is to have it be an eventually database agnostic terminal spreadsheet kind of program. Lots planned for the future!

Please add instructions on how to build it. Looking forward to trying it out!

I absolutely will as soon as I can! I just started it two days ago and was kind of blown away by the response, so the readme definitely didn't get a lot of attention.

I'll remedy that!

Cloning to `~/go` and running `go build` worked for me. But I can never remember how to build Go projects, so adding more details in the README would be nice.

Very well done! Great project!

Really cool, I’m a big user of SQLite. Reminds me of visidata but for SQLite: https://github.com/saulpw/visidata

Visidata can view SQLite too: https://www.visidata.org/docs/formats/

Hey everyone! Author here. In order to better reflect my future plans for the project, I have rebranded of sorts. It is now called termdbms (suggestions on a better name welcome), because eventually I would like to become database agnostic. MySQL support is planned for the alpha 1.0 release!

a vote for Postgres here!

Added to the list!

You will eventually be able to run SQL queries on the database within the application. I hope to blend that with spreadsheet-like user interface so its easy to add or remove rows, columns, values, rename, etc...

Thank you for your work, this looks terrific for exploring databases that one is unfamiliar with. Like we do when joining an extant project.

If there was a nice way to explore the tables that would be great. Such as filter by table name, and show how many records are in each table. Or even a way to show which tables reference other tables.

I can easily do all those but references and foreign keys. Not even going to think about that until alpha 3.

Yeah, that is definitely an advanced feature. I'll be watching this repo, thank you!

mySQLite ; name suggestion

Large databases are thousands of rows? My small database already has a few tens of thousands.

Who considers a few thousand rows large?

One person’s small is another person’s large. It all comes down to your typical use cases; no surprise there. I have lots of tiny sqlite databases myself, so for me, a few tens of thousands rows is large. But at least I am well aware that multi-gigabyte sqlite databases can and do exist.

For SQLite seems reasonable? I remember it advertised as ini file replacement as well :)

Sqlite easily manages millions of rows. I’ve used it in the past as part of a lazier implementation of an ELK-like stack and it worked fine.

Optimizations like that will be part of the next alpha release after the one I'm working on.

I just honestly cannot imagine how it could start to be slow at a few thousand rows. Calling it an optimization feels wrong somehow.

Glad you hear you are planning to look at it though :)

Larger querying larger databases should be a problem for the RDBMS not for the UI wrapper. So I’d wager he is processing every record on the db irrespective of whether it’s visible on screen or not. It would explain the TUI panic posted elsewhere too.

I have no control over which portions of the screen get updated when without updating the library I'm using.

One way to optimise this is to pull back the entire SQL results in an [][]interface{} (row, column) but then only pass a sub-slice to your TUI (depending on how many rows are visible).

I assume your term library doesn’t create the actual table? So you’d know the term height and you’re then plotting the cells? If that’s not the case then I don’t think you’ll get much further with this project without switching to another term library (or rolling your own — which is actually easier than it sounds).

Lol I just did this. Now way faster and can handle arbitrary amounts of data (there is some flickering on scroll for large data sets I'm trying to sort out).

That it was written at all is what matters. Mentioning that it was written in Go simply tells us that it's fast enough for a cli and is a single binary. Yet, many existing python utilities in this class are also fast enough and not backed by a single binary.

> NOTE: Mouse controls don't work for remote sessions like serial or SSH.

That's weird. I'm having a hard time imagining how it would be possible to break mouse controls over SSH, since the escape sequences used to signal mouse events are transport-agnostic.

Me too. Maybe it is the latency that affected this decision. If the cause for ignoring mouse events is latency, Mosh may be a bit better.

https://mosh.org/

I haven't looked into that one too much, I'll thoroughly test it soon.

For whatever reason I only tested Windows ssh, since it's what I use for work. I'll test Linux soon.

I just tested it. Mouse works in Linux over SSH, but I'm not really sure how to use the app otherwise (:.

And yeah, it crashes on larger databases:

  panic: runtime error: slice bounds out of range [:-1]                                                                                                                                                                                                                                                                                                                                                                             
  
  goroutine 54 [running]:
  sqlite3-viewer/viewer.TruncateIfApplicable(0xc02037ef70, {0xc000126038, 0x7})
   ~/go/tuitty/viewer/util.go:99 +0x192
  sqlite3-viewer/viewer.TuiModel.View.func2(0xc000818f60)
   ~/go/tuitty/viewer/viewer.go:121 +0xae5
  created by sqlite3-viewer/viewer.TuiModel.View
   ~/go/tuitty/viewer/viewer.go:106 +0x272

Not sure if your data is not sensitive enough that you'd open an issue and attach it? I'd use it for testing.

Very nice ! Wish I could build the schema, then this would be Microsoft Access in a terminal !

I have lots of plans including database creation. It's in its infancy now but 2-3 months from now that should be possible.

Very nice!

Thank you!

I've built a similar project (backed by Sqlite), though it's full GUI.

At work, I work with a lot of CSVs. I often hit the limit of Excel and Google Sheets. Plus, using formula is difficult. The ergonomics around it is also not great (e.g. am I suppose to write long formula in a one-line box at the top?)

Eventually, I've decided to create Superintendent that enables me to write SQL on CSVs.

I'm working on optimizing it to be faster and faster. Currently, it can load 1GB CSV on Mac Pro 2020 within 10 seconds because it basically goes to C code.

I'm looking to make it feel more and more like a spreadsheet (e.g. click to sort, copy row, copy column, edit it directly) while giving focus to SQL writing. I'm loving it so far, but there are still a lot of improvements to be made.

If you are interested, please check it out: https://superintendent.app

Not open source? Hard pass. Welcome to 2021.

The supermarket down the street is now taking Git Pull Requests for grocery.

The legend still lives on. We've heard they still goes through shops in their town and shout "Hard pass" to this day.

Now fully automated using SuperMarket X FLOSS tool written in Go.

Here is your opportunity to make it happen then,

https://www.rewe-digital.com/stellenangebote/649-go-develope...