Describe the bug dblab does not start on Windows given an sqlite db. It fails with error message Error: Binary was compiled with 'CGO_ENABLED=0', go-sqlite3 requires cgo to work. This is a stub

To Reproduce Steps to reproduce the behavior:

1. Download dblab_0.16.0_windows_amd64.tar.gz
2. Extract
3. Open Windows-Terminal app in extracted Folder
4. Try to open an sqlite db by running .\dblab.exe --driver sqlite3 --db "P:\ath\To\sqlite.db"

Expected behavior dblab opens

OS (please complete the following information):

• Microsoft Windows 10 Pro x64 Version 10.0.19044 Build 19044

Describe the bug when try to execute dblab-sqlite on OSX gives this error

Error: Binary was compiled with 'CGO_ENABLED=0', go-sqlite3 requires cgo to work. This is a stub

To Reproduce Steps to reproduce the behavior:

1. Download https://github.com/danvergara/dblab/releases/download/v0.16.0/dblab_0.16.0_darwin_arm64.tar.gz
2. extract and move executable to a directory on path
3. execute it
4. See error

Expected behavior open the database and show the content

Screenshots

OS (please complete the following information): ❱ uname -a Darwin mary3jane.local 21.6.0 Darwin Kernel Version 21.6.0: Mon Aug 22 20:19:52 PDT 2022; root:xnu-8020.140.49~2/RELEASE_ARM64_T6000 arm64

Additional context Add any other context about the problem here.

Pull Request Template

Description

Add CODE_OF_CONDUCT.md and CONTRIBUTING.md files

Fixes #38

Type of change

Please delete options that are not relevant.

• [x] This change requires a documentation update

Checklist:

• [x] I have made corresponding changes to the documentation
• [x] I have checked my code and corrected any misspellings

Describe the bug When dblab is compiled with Go 1.17.3 on Darwin on an x86_64 platform, it panics on startup.

fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0xb01dfacedebac1e pc=0x7fff6c1cf70a]

runtime stack:
runtime: unexpected return pc for runtime.sigpanic called from 0x7fff6c1cf70a
stack: frame={sp:0x7ffeefbff5f8, fp:0x7ffeefbff648} stack=[0x7ffeefb80698,0x7ffeefbff700)
0x00007ffeefbff4f8:  0x01007ffeefbff518  0x0000000000000004 
0x00007ffeefbff508:  0x000000000000001f  0x00007fff6c1cf70a 
0x00007ffeefbff518:  0x0b01dfacedebac1e  0x0000000000000001 
0x00007ffeefbff528:  0x00000000040388d1 <runtime.throw+0x0000000000000071>  0x00007ffeefbff5c8 
0x00007ffeefbff538:  0x00000000045fa820  0x00007ffeefbff580 
0x00007ffeefbff548:  0x0000000004038b88 <runtime.fatalthrow.func1+0x0000000000000048>  0x00000000049e3720 
0x00007ffeefbff558:  0x0000000000000001  0x0000000000000001 
0x00007ffeefbff568:  0x00007ffeefbff5c8  0x00000000040388d1 <runtime.throw+0x0000000000000071> 
0x00007ffeefbff578:  0x00000000049e3720  0x00007ffeefbff5b8 
0x00007ffeefbff588:  0x0000000004038b10 <runtime.fatalthrow+0x0000000000000050>  0x00007ffeefbff598 
0x00007ffeefbff598:  0x0000000004038b40 <runtime.fatalthrow.func1+0x0000000000000000>  0x00000000049e3720 
0x00007ffeefbff5a8:  0x00000000040388d1 <runtime.throw+0x0000000000000071>  0x00007ffeefbff5c8 
0x00007ffeefbff5b8:  0x00007ffeefbff5e8  0x00000000040388d1 <runtime.throw+0x0000000000000071> 
0x00007ffeefbff5c8:  0x00007ffeefbff5d0  0x0000000004038900 <runtime.throw.func1+0x0000000000000000> 
0x00007ffeefbff5d8:  0x0000000004601a8b  0x000000000000002a 
0x00007ffeefbff5e8:  0x00007ffeefbff638  0x000000000404e3f6 <runtime.sigpanic+0x0000000000000396> 
0x00007ffeefbff5f8: <0x0000000004601a8b  0x00000000049e3720 
0x00007ffeefbff608:  0x00007ffeefbff678  0x000000000402b666 <runtime.(*mheap).allocSpan+0x0000000000000546> 
0x00007ffeefbff618:  0x000000c00020e000  0x0000000000008000 
0x00007ffeefbff628:  0x00007fff00000008  0x0000000000000000 
0x00007ffeefbff638:  0x00007ffeefbff680 !0x00007fff6c1cf70a 
0x00007ffeefbff648: >0x00007ffeefbff680  0x0000000004938000 
0x00007ffeefbff658:  0x000000000000059a  0x00000000042cd365 <golang.org/x/sys/unix.libc_ioctl_trampoline+0x0000000000000005> 
0x00007ffeefbff668:  0x000000000406aa3f <runtime.syscall+0x000000000000001f>  0x000000c0001cb848 
0x00007ffeefbff678:  0x00007ffeefbff6c0  0x000000c0001cb818 
0x00007ffeefbff688:  0x00000000040688b0 <runtime.asmcgocall+0x0000000000000070>  0x0000000000000004 
0x00007ffeefbff698:  0x0000000004018700 <runtime.evacuate_faststr+0x0000000000000220>  0x8700000000001018 
0x00007ffeefbff6a8:  0x0000000000000010  0x0000000004a17e78 
0x00007ffeefbff6b8:  0x0000000000000810  0x000000c0000001a0 
0x00007ffeefbff6c8:  0x00000000040669c9 <runtime.systemstack+0x0000000000000049>  0x0000000000000004 
0x00007ffeefbff6d8:  0x0000000004687060  0x00000000049e3720 
0x00007ffeefbff6e8:  0x00007ffeefbff738  0x00000000040668c5 <runtime.mstart+0x0000000000000005> 
0x00007ffeefbff6f8:  0x000000000406687d <runtime.rt0_go+0x000000000000013d> 
runtime.throw({0x4601a8b, 0x49e3720})
	/opt/macports-test/lib/go/src/runtime/panic.go:1198 +0x71
runtime: unexpected return pc for runtime.sigpanic called from 0x7fff6c1cf70a
stack: frame={sp:0x7ffeefbff5f8, fp:0x7ffeefbff648} stack=[0x7ffeefb80698,0x7ffeefbff700)
0x00007ffeefbff4f8:  0x01007ffeefbff518  0x0000000000000004 
0x00007ffeefbff508:  0x000000000000001f  0x00007fff6c1cf70a 
0x00007ffeefbff518:  0x0b01dfacedebac1e  0x0000000000000001 
0x00007ffeefbff528:  0x00000000040388d1 <runtime.throw+0x0000000000000071>  0x00007ffeefbff5c8 
0x00007ffeefbff538:  0x00000000045fa820  0x00007ffeefbff580 
0x00007ffeefbff548:  0x0000000004038b88 <runtime.fatalthrow.func1+0x0000000000000048>  0x00000000049e3720 
0x00007ffeefbff558:  0x0000000000000001  0x0000000000000001 
0x00007ffeefbff568:  0x00007ffeefbff5c8  0x00000000040388d1 <runtime.throw+0x0000000000000071> 
0x00007ffeefbff578:  0x00000000049e3720  0x00007ffeefbff5b8 
0x00007ffeefbff588:  0x0000000004038b10 <runtime.fatalthrow+0x0000000000000050>  0x00007ffeefbff598 
0x00007ffeefbff598:  0x0000000004038b40 <runtime.fatalthrow.func1+0x0000000000000000>  0x00000000049e3720 
0x00007ffeefbff5a8:  0x00000000040388d1 <runtime.throw+0x0000000000000071>  0x00007ffeefbff5c8 
0x00007ffeefbff5b8:  0x00007ffeefbff5e8  0x00000000040388d1 <runtime.throw+0x0000000000000071> 
0x00007ffeefbff5c8:  0x00007ffeefbff5d0  0x0000000004038900 <runtime.throw.func1+0x0000000000000000> 
0x00007ffeefbff5d8:  0x0000000004601a8b  0x000000000000002a 
0x00007ffeefbff5e8:  0x00007ffeefbff638  0x000000000404e3f6 <runtime.sigpanic+0x0000000000000396> 
0x00007ffeefbff5f8: <0x0000000004601a8b  0x00000000049e3720 
0x00007ffeefbff608:  0x00007ffeefbff678  0x000000000402b666 <runtime.(*mheap).allocSpan+0x0000000000000546> 
0x00007ffeefbff618:  0x000000c00020e000  0x0000000000008000 
0x00007ffeefbff628:  0x00007fff00000008  0x0000000000000000 
0x00007ffeefbff638:  0x00007ffeefbff680 !0x00007fff6c1cf70a 
0x00007ffeefbff648: >0x00007ffeefbff680  0x0000000004938000 
0x00007ffeefbff658:  0x000000000000059a  0x00000000042cd365 <golang.org/x/sys/unix.libc_ioctl_trampoline+0x0000000000000005> 
0x00007ffeefbff668:  0x000000000406aa3f <runtime.syscall+0x000000000000001f>  0x000000c0001cb848 
0x00007ffeefbff678:  0x00007ffeefbff6c0  0x000000c0001cb818 
0x00007ffeefbff688:  0x00000000040688b0 <runtime.asmcgocall+0x0000000000000070>  0x0000000000000004 
0x00007ffeefbff698:  0x0000000004018700 <runtime.evacuate_faststr+0x0000000000000220>  0x8700000000001018 
0x00007ffeefbff6a8:  0x0000000000000010  0x0000000004a17e78 
0x00007ffeefbff6b8:  0x0000000000000810  0x000000c0000001a0 
0x00007ffeefbff6c8:  0x00000000040669c9 <runtime.systemstack+0x0000000000000049>  0x0000000000000004 
0x00007ffeefbff6d8:  0x0000000004687060  0x00000000049e3720 
0x00007ffeefbff6e8:  0x00007ffeefbff738  0x00000000040668c5 <runtime.mstart+0x0000000000000005> 
0x00007ffeefbff6f8:  0x000000000406687d <runtime.rt0_go+0x000000000000013d> 
runtime.sigpanic()
	/opt/macports-test/lib/go/src/runtime/signal_unix.go:719 +0x396

goroutine 1 [syscall, locked to thread]:
syscall.syscall(0x42cd360, 0x1, 0x40487413, 0xc0001cb8d8)
	/opt/macports-test/lib/go/src/runtime/sys_darwin.go:22 +0x3b fp=0xc0001cb848 sp=0xc0001cb828 pc=0x40655db
syscall.syscall(0x40a9ca6, 0x4012514, 0xc0001cb900, 0x40a9bd8)
	<autogenerated>:1 +0x26 fp=0xc0001cb890 sp=0xc0001cb848 pc=0x406b246
golang.org/x/sys/unix.ioctl(0x45ea62d, 0x4, 0x1000000000008)
	/Users/hgillot/go/pkg/mod/golang.org/x/[email protected]/unix/zsyscall_darwin_amd64.go:689 +0x39 fp=0xc0001cb8c0 sp=0xc0001cb890 pc=0x42ccff9
golang.org/x/sys/unix.IoctlGetTermios(...)
	/Users/hgillot/go/pkg/mod/golang.org/x/[email protected]/unix/ioctl.go:72
github.com/mattn/go-isatty.IsTerminal(0x45ea62d)
	/Users/hgillot/go/pkg/mod/github.com/mattn/[email protected]/isatty_bsd.go:10 +0x50 fp=0xc0001cb930 sp=0xc0001cb8c0 pc=0x42cd470
github.com/fatih/color.init()
	/Users/hgillot/go/pkg/mod/github.com/fatih/[email protected]/color.go:21 +0x7a fp=0xc0001cb968 sp=0xc0001cb930 pc=0x42cdc5a
runtime.doInit(0x4941200)
	/opt/macports-test/lib/go/src/runtime/proc.go:6498 +0x123 fp=0xc0001cbaa0 sp=0xc0001cb968 pc=0x4048063
runtime.doInit(0x49411a0)
	/opt/macports-test/lib/go/src/runtime/proc.go:6475 +0x71 fp=0xc0001cbbd8 sp=0xc0001cbaa0 pc=0x4047fb1
runtime.doInit(0x493e300)
	/opt/macports-test/lib/go/src/runtime/proc.go:6475 +0x71 fp=0xc0001cbd10 sp=0xc0001cbbd8 pc=0x4047fb1
runtime.doInit(0x4941b00)
	/opt/macports-test/lib/go/src/runtime/proc.go:6475 +0x71 fp=0xc0001cbe48 sp=0xc0001cbd10 pc=0x4047fb1
runtime.doInit(0x493c780)
	/opt/macports-test/lib/go/src/runtime/proc.go:6475 +0x71 fp=0xc0001cbf80 sp=0xc0001cbe48 pc=0x4047fb1
runtime.main()
	/opt/macports-test/lib/go/src/runtime/proc.go:238 +0x1e6 fp=0xc0001cbfe0 sp=0xc0001cbf80 pc=0x403af26
runtime.goexit()
	/opt/macports-test/lib/go/src/runtime/asm_amd64.s:1581 +0x1 fp=0xc0001cbfe8 sp=0xc0001cbfe0 pc=0x4068ba1

To Reproduce Steps to reproduce the behavior:

1. Ensure running macOS on an x86_64 Intel host
2. Ensure Go is version 1.17+
3. Checkout dblab and switch to v0.13.0 branch
4. make build
5. Attempt to run dblab

Expected behavior dblab runs normally.

OS (please complete the following information):

• macOS Catalina 10.15.7, Intel x85_64

Additional context

• Go 1.17.3

Is your feature request related to a problem? Please describe. No, not at all.

Describe the solution you'd like I really like the --config flag and I was wondering if it could be possible to add support for multiple configurations. I think that most developers using this tool have a local database, maybe another local database only used for testing purposes, and then a database for each environment in which the deploy their code.

Describe alternatives you've considered The alternative is to add all your configurations in the $HOME/.dblab.yaml file and comment them, except the one you're going to use.

Additional context dblab is a nice tool so thanks a lot for making it.

Describe the bug

Currently resizing the terminal does not redraw the UI leaving it the wrong size and data hidden.

To Reproduce Steps to reproduce the behavior:

1. Launch dblab
2. Resize terminal

Expected behavior The UI to redraw to the new terminal size.

Screenshots If applicable, add screenshots to help explain your problem.

OS (please complete the following information):

• Linux archlinux 5.19.3-arch1-1 x86_64 GNU/Linux
• alacritty terminal
• tmux

Additional context Add any other context about the problem here.

Pull Request Template

Description

@israteneda requested a few months back, at the time I wasn't sure about it and how to introduce this kind of support, mostly because I wasn't aware of the current relevance of sqlite3 for the modern software development.

Fixes #49

Type of change

Please delete options that are not relevant.

• [ ] Bug fix (non-breaking change which fixes an issue)
• [X] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [X] This change requires a documentation update

How Has This Been Tested?

I added a new service in the docker compose file to run same process as we do for other databases like postgres or mysql. That I could have a pretty similar experience to run the TUI client.

Checklist:

• [X] My code follows the style guidelines of this project
• [X] I have performed a self-review of my own code
• [X] I have commented my code, particularly in hard-to-understand areas
• [X] I have made corresponding changes to the documentation
• [X] I have added tests that prove my fix is effective or that my feature works
• [X] New and existing unit tests pass locally with my changes
• [X] I have checked my code and corrected any misspellings

Is your feature request related to a problem? Please describe. The current framework that dbladb relies on is gocui, but is not under active development. So, if we spot a nasty bug or we can add extra functionality out of those we currently have, we're not gonna be able fix or add them.

Describe the solution you'd like I'm proposing to migrate to lipbgloss, which is another alternative that is under active development and looks nicer than the current solution.

Describe alternatives you've considered I considered temui, but it's not an option because of the lack of critical features. I was a direct competitor to gocui at the beginning.

Additional context I'm considering to add a view to show the schema of the selected table on the interface, but currenly we don't have available space to do so. I'm thinking to take advantage of the tabs feature that lipgloss provides as show below:

Describe the bug Unable to connect to mariadb when password contains characters '@#'

To Reproduce Steps to reproduce the behavior: Connect to mariadb or mysql with a password containing '@#' e.g.

./dblab --driver mysql --host xyz.abc.db.skysql.net --user myuser --pass 5@klkbN#ABC--ssl enable --port 5001

or

./dblab --driver mysql --host xyz.abc.db.skysql.net --user myuser --pass '5@klkbN#ABC'--ssl enable --port 5001

Receive this error: Error: Error 1045: Access denied for user 'redacted'@'redactedip' (using password: YES)

Expected behavior Connects

Screenshots If applicable, add screenshots to help explain your problem.

OS (please complete the following information):

• MacOS BigSur 11.2.3

Describe the bug I was thinking that sqlite3 option should ask for the path of the SQLite file instead of host and port. What do you think?

To Reproduce Steps to reproduce the behavior:

1. Build the app with the latest updates
2. run ./dblab
3. select sqlite3 option
4. The prompt asks for host and port

Expected behavior I think the app should ask for the path of the SQLite file

Screenshots

OS (please complete the following information):

• MacOS Monterey v12.4

Additional context N/A

Describe the bug When pressing 'Enter' on a table, dblab crashes saying 'unknown column 'tc.enforced' in field list

To Reproduce Steps to reproduce the behavior:

1. Load a database
2. Go to a table and press enter

Expected behavior Should so table structure

OS (please complete the following information): Arch linux

Additional context This is when connecting to a mariaDB database

Hello,

most databases I have to work with have no password for root user. They use socket auth instead.

 mysql -S /var/run/mysqld/mysqld.sock

  -S, --socket=name   The socket file to use for connection.

Can that be supported?

Cheers!

Pull Request Template

Description

Saving the config whendblab is executed for the first time, or if we run dblab with the flag --config The new config will be saved at $HOME/.dblab.yaml

Fixes #90

Type of change

Please delete options that are not relevant.

• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [x] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [x] This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

Checklist:

• [ ] My code follows the style guidelines of this project
• [x] I have performed a self-review of my own code
• [ ] I have commented my code, particularly in hard-to-understand areas
• [ ] I have made corresponding changes to the documentation
• [ ] I have added tests that prove my fix is effective or that my feature works
• [ ] New and existing unit tests pass locally with my changes
• [ ] I have checked my code and corrected any misspellings

Is your feature request related to a problem? Please describe. I was using dblab, and I noticed that I had to enter my configuration every time I run dblab without --config flag Describe the solution you'd like I think it could be cool to have the option to save the first time configuration, so we can get the existing configuration after the first time I run dblab. So with don't have to run ./dblab --config every time that we want to run the app. Describe alternatives you've considered It works well with --config flag Additional context I'm not sure where the configuration could be saved Also, what happen if I would rather not use the first time configuration anymore 🤔

Is your feature request related to a problem? Please describe.

It's odd to see that when a database container is shutting down, dblab doesn't do anything about it. The expected behavior: when that happen, dblab should return an error message.

Describe the solution you'd like

It would be nice if dblab let you know that the session/connection has expired and then display some sort of form to get the new values for a new database connection (just like pgweb does).

Describe alternatives you've considered

Another options is just stop the execution and show an error message on the std output.

Is your feature request related to a problem? Please describe. Many other database clients stores the encrypted connection, somewhere. It'd be nice to have something like that available on dblab.

Describe the solution you'd like dblab may have a system intended to store previous connections, somewhere in the local file system. We may add a flag to access to an special menu with the list of the old connections, be able to select one, and provide a password and decrypt it to open a connection with the database.

Describe alternatives you've considered Don't have other alternatives