7 ms·

Usql: v0.7.0 released

112 points by kenshaw 8y ago

kenshaw 8y ago
Just released the latest version of usql, which fixes issues with syntax highlighting, adds initial support for Cassandra databases via CQL, among other changes. If you've not seen usql before, it's a universal command-line client for SQL databases (and now also Cassandra), modeled on psql. usql makes it easy to work from the command-line, in a simple and consistent way across any database and on any platform (Windows, macOS, Linux). usql is written in Go, and provides things like syntax highlighting and compatibility with databases other than PostgreSQL (see below for the list of the supported databases). Progress is moving at a decent clip towards a v1.0, which I expect to include 100% native Go support for Oracle databases, tab-completion, full compatibility with psql's \pset (and other output formatting) commands. usql supports the following databases: Microsoft SQL Server MySQL PostgreSQL SQLite3 Oracle Apache Avatica Cassandra ClickHouse Couchbase Cznic QL Firebird SQL Microsoft ADODB (Windows only) ODBC Presto SAP HANA VoltDB Hope others in the community can make use of usql. Glad to answer any questions if anyone has any.
- bruce_one 8y ago
  100% native Go support for Oracle sounds amazing (I'm reading that as meaning no instantclient sdk requirement, just to confirm (which might be wrong...)). Is there an issue/pr/library for that work? It will very much enter the toolbox for all situations if that can happen :-) (Looking for something better than sqlplus is always why I end up looking into usql...) usql is super cool, thank you for all the work you've done with it :-)
  - kenshaw 8y ago
    Yes, I've been working on a 100% native Go driver for Oracle. It is not even alpha or beta quality at this time.
    - grumpydba 8y ago
      Hi, can I see the code, and can I help? I have a beta SAP ASE driver that should come out soon, BTW.
      - kenshaw 8y ago
        It's more of a passionate side project at the moment, as I am still reverse engineering the protocols involved. It's not close to completion, but I'm hoping to have it done sometime in the next few months. It's not a high priority, as there are other ways to connect to Oracle. My goal is to get rid of all the non-Go dependencies, which would (for the first time, ever) finally make it a reality to have a single, small binary that can connect to "every" database and that can be freely distributed. If you'd like to help, please feel free to start an implementation. While I'm not following a specific development routine for the native Oracle driver, I do have a repository with a bunch of (non-building) code that I made to assist with inspecting the raw protocol captures.
        grumpydba 8y ago
        Someone has already been there, the protocol is very.. rich, I would say: https://blog.pythian.com/repost-oracle-protocol/ https://blog.pythian.com/repost-oracle-protocol/
        tracker1 8y ago
        Hell, if that lead to Oracle drivers for other languages, that could be amazing too. It's nearly incomprehensible to me why Oracle hasn't documented their protocol.
        emmelaich 8y ago
        Then it would difficult to change. For instance to support clusters and failover.
        grumpydba 8y ago
- userbinator 8y ago
  ODBC isn't a "database" per se, but a standard interface that can access any database with an ODBC driver. ...and although I'm not familiar with all of the others in that list, the ones that I do recognise have ODBC drivers.
  - staz 8y ago
    I read that has the client having specific support for these DB but a fallback to generic ODBC otherwhise
  - kenshaw 8y ago
    Yes and no. ODBC on Windows may (or may not) be provided by the Microsoft JET driver, which can be considered a database unto itself. Specifically, there is a separate ODBC driver for Go that usql supports, which is what this is reflective of. I actually edited the above after posting to remove a double entry for PostgreSQL and MySQL, as there are two different Go drivers for each of those databases (4 in total) that are well supported by the community.
- bobbydreamer 8y ago
  No Db2
- SloopJon 8y ago
  When I type help, the characters aren't echoed to the screen, but backslash commands are: $ ./usql Type "help" for help. (not connected)=> You are using usql, ... Type: \copyright for distribution terms \? for help with usql commands \g or terminate with semicolon ... \q to quit (not connected)=> \q $ Is this expected? Edit: I'm using the binary package on macOS 10.12.6.
  - kenshaw 8y ago
    This is a syntax highlighting issue, most likely. The \ commands are not highlighted. Are you using a white or light colored background? Likely the contrast isn't high enough. I just updated the documentation with more information on controlling syntax highlighting. You can either try disabling syntax highlighting completely ( \set SYNTAX_HL false ) or change the Chroma style used ( \set SYNTAX_HL_STYLE paraiso-light ) See this page: https://xyproto.github.io/splash/docs/all.html https://xyproto.github.io/splash/docs/all.html for an example of what the various Chroma styles should look like.
marzell 8y ago
usql != U-SQL. One is a database client, the other a database language. This could become confusing.
- go_prodev 8y ago
  Usql != Transoft U/SQL either
wenc 8y ago
How would this compare to DBCLI? http://www.dbcli.com/ http://www.dbcli.com/ pgcli https://www.pgcli.com/ https://www.pgcli.com/ mycli https://www.mycli.net/ https://www.mycli.net/
- amjith 8y ago
  I'm the creator of dbcli. I can give you my perspective. usql is a great tool if you're familiar with Postgres' psql client and wish you could use it for other databases like MySQL, Cassandra etc. dbcli tools are designed to preserve the usage semantics of the existing tools but improve on them by providing auto-completion. For instance you can use `\d` in pgcli and `SHOW TABLES` in mycli. This was a conscious decision to make pgcli and mycli drop in replacements for of MySQL and psql. I was also working under the assumption that people rarely use multiple databases, you're either a postgres shop or a MySQL shop. If you have a mix of both, there is a good chance that not a single person is interacting with both of them on a daily basis. You have different teams using different databases. But my reasoning there could be flawed. There is nothing stopping someone from adding an adapter to the usql tool to make it behave like MySQL (because they like the mysql client better) based on a command line argument, for instance.
  - justinclift 8y ago
    As a data point, it seems to be reasonably common for people to use both SQLite + <some other database> (eg PG). Probably because they have different use cases that don't overlap too much. eg SQLite is great for single file info storage and passing around. The others - being competing multi user servers - don't do that. :)
    - laumars 8y ago
      Up until very recently I used to regularly hop between sqlite3, Informix (don't hear much about that these days), MySQL (or compatible) and some key/value stores like Redis and memcache. Occasionally used to dip into MSSQL too but that wasn't often.
- kenshaw 8y ago
simplecomplex 8y ago
SQL is an initialism. Please capitalize it, as it should be. It stands for Standard Query Language.
- beart 8y ago
  A very large portion of developers I speak to pronounce it as 'seekwol'. Some of them also prefer tabs.
  - simplecomplex 8y ago
    Acronyms should also be capitalized.
    - igitur 8y ago
      You mean like laser, radar and scuba?
  - kenshaw 8y ago
    I think they're saying "SEQUEL", which is the widely accepted/recognized pronounced mononym for "SQL".
- go_prodev 8y ago
  S = structured, not standard
  - laumars 8y ago
    Indeed. There's definitely nothing standard about sql (intentionally lower cased for fun) what with every DB out there adopting their own set of features. Even the core syntax of sql can vary significantly eg joining tables in Oracle's PL/SQL vs ANSI SQL (eg MySQL). When something as basic to the concept of sql as table joins can very so significantly, you have to question what the GP was smoking to assume the "S" in SQL stood for "Standard" :P As an aside, I also love the fact he presumed the author of usql - someone who has been reverse engineering undocumented drivers to bring support to Go(lang) - was unaware of what the name of his own tool and the language it exposes stood for, is just laughable.

112 points by kenshaw 8y ago

Just released the latest version of usql, which fixes issues with syntax highlighting, adds initial support for Cassandra databases via CQL, among other changes. If you've not seen usql before, it's a universal command-line client for SQL databases (and now also Cassandra), modeled on psql. usql makes it easy to work from the command-line, in a simple and consistent way across any database and on any platform (Windows, macOS, Linux). usql is written in Go, and provides things like syntax highlighting and compatibility with databases other than PostgreSQL (see below for the list of the supported databases). Progress is moving at a decent clip towards a v1.0, which I expect to include 100% native Go support for Oracle databases, tab-completion, full compatibility with psql's \pset (and other output formatting) commands. usql supports the following databases: Microsoft SQL Server MySQL PostgreSQL SQLite3 Oracle Apache Avatica Cassandra ClickHouse Couchbase Cznic QL Firebird SQL Microsoft ADODB (Windows only) ODBC Presto SAP HANA VoltDB Hope others in the community can make use of usql. Glad to answer any questions if anyone has any.

bruce_one 8y ago
100% native Go support for Oracle sounds amazing (I'm reading that as meaning no instantclient sdk requirement, just to confirm (which might be wrong...)). Is there an issue/pr/library for that work? It will very much enter the toolbox for all situations if that can happen :-) (Looking for something better than sqlplus is always why I end up looking into usql...) usql is super cool, thank you for all the work you've done with it :-)
- kenshaw 8y ago
  Yes, I've been working on a 100% native Go driver for Oracle. It is not even alpha or beta quality at this time.
  - grumpydba 8y ago
    Hi, can I see the code, and can I help? I have a beta SAP ASE driver that should come out soon, BTW.
    - kenshaw 8y ago
      It's more of a passionate side project at the moment, as I am still reverse engineering the protocols involved. It's not close to completion, but I'm hoping to have it done sometime in the next few months. It's not a high priority, as there are other ways to connect to Oracle. My goal is to get rid of all the non-Go dependencies, which would (for the first time, ever) finally make it a reality to have a single, small binary that can connect to "every" database and that can be freely distributed. If you'd like to help, please feel free to start an implementation. While I'm not following a specific development routine for the native Oracle driver, I do have a repository with a bunch of (non-building) code that I made to assist with inspecting the raw protocol captures.
      - grumpydba 8y ago
        Someone has already been there, the protocol is very.. rich, I would say: https://blog.pythian.com/repost-oracle-protocol/ https://blog.pythian.com/repost-oracle-protocol/
      - tracker1 8y ago
        Hell, if that lead to Oracle drivers for other languages, that could be amazing too. It's nearly incomprehensible to me why Oracle hasn't documented their protocol.
        emmelaich 8y ago
        Then it would difficult to change. For instance to support clusters and failover.
        grumpydba 8y ago
userbinator 8y ago
ODBC isn't a "database" per se, but a standard interface that can access any database with an ODBC driver. ...and although I'm not familiar with all of the others in that list, the ones that I do recognise have ODBC drivers.
- staz 8y ago
  I read that has the client having specific support for these DB but a fallback to generic ODBC otherwhise
- kenshaw 8y ago
  Yes and no. ODBC on Windows may (or may not) be provided by the Microsoft JET driver, which can be considered a database unto itself. Specifically, there is a separate ODBC driver for Go that usql supports, which is what this is reflective of. I actually edited the above after posting to remove a double entry for PostgreSQL and MySQL, as there are two different Go drivers for each of those databases (4 in total) that are well supported by the community.
bobbydreamer 8y ago
No Db2
SloopJon 8y ago
When I type help, the characters aren't echoed to the screen, but backslash commands are: $ ./usql Type "help" for help. (not connected)=> You are using usql, ... Type: \copyright for distribution terms \? for help with usql commands \g or terminate with semicolon ... \q to quit (not connected)=> \q $ Is this expected? Edit: I'm using the binary package on macOS 10.12.6.
- kenshaw 8y ago
  This is a syntax highlighting issue, most likely. The \ commands are not highlighted. Are you using a white or light colored background? Likely the contrast isn't high enough. I just updated the documentation with more information on controlling syntax highlighting. You can either try disabling syntax highlighting completely ( \set SYNTAX_HL false ) or change the Chroma style used ( \set SYNTAX_HL_STYLE paraiso-light ) See this page: https://xyproto.github.io/splash/docs/all.html https://xyproto.github.io/splash/docs/all.html for an example of what the various Chroma styles should look like.

marzell 8y ago

usql != U-SQL. One is a database client, the other a database language. This could become confusing.

go_prodev 8y ago
Usql != Transoft U/SQL either

wenc 8y ago

How would this compare to DBCLI? http://www.dbcli.com/ http://www.dbcli.com/ pgcli https://www.pgcli.com/ https://www.pgcli.com/ mycli https://www.mycli.net/ https://www.mycli.net/

amjith 8y ago
I'm the creator of dbcli. I can give you my perspective. usql is a great tool if you're familiar with Postgres' psql client and wish you could use it for other databases like MySQL, Cassandra etc. dbcli tools are designed to preserve the usage semantics of the existing tools but improve on them by providing auto-completion. For instance you can use `\d` in pgcli and `SHOW TABLES` in mycli. This was a conscious decision to make pgcli and mycli drop in replacements for of MySQL and psql. I was also working under the assumption that people rarely use multiple databases, you're either a postgres shop or a MySQL shop. If you have a mix of both, there is a good chance that not a single person is interacting with both of them on a daily basis. You have different teams using different databases. But my reasoning there could be flawed. There is nothing stopping someone from adding an adapter to the usql tool to make it behave like MySQL (because they like the mysql client better) based on a command line argument, for instance.
- justinclift 8y ago
  As a data point, it seems to be reasonably common for people to use both SQLite + <some other database> (eg PG). Probably because they have different use cases that don't overlap too much. eg SQLite is great for single file info storage and passing around. The others - being competing multi user servers - don't do that. :)
  - laumars 8y ago
    Up until very recently I used to regularly hop between sqlite3, Informix (don't hear much about that these days), MySQL (or compatible) and some key/value stores like Redis and memcache. Occasionally used to dip into MSSQL too but that wasn't often.
kenshaw 8y ago

simplecomplex 8y ago

SQL is an initialism. Please capitalize it, as it should be. It stands for Standard Query Language.

beart 8y ago
A very large portion of developers I speak to pronounce it as 'seekwol'. Some of them also prefer tabs.
- simplecomplex 8y ago
  Acronyms should also be capitalized.
  - igitur 8y ago
    You mean like laser, radar and scuba?
- kenshaw 8y ago
  I think they're saying "SEQUEL", which is the widely accepted/recognized pronounced mononym for "SQL".
go_prodev 8y ago
S = structured, not standard
- laumars 8y ago
  Indeed. There's definitely nothing standard about sql (intentionally lower cased for fun) what with every DB out there adopting their own set of features. Even the core syntax of sql can vary significantly eg joining tables in Oracle's PL/SQL vs ANSI SQL (eg MySQL). When something as basic to the concept of sql as table joins can very so significantly, you have to question what the GP was smoking to assume the "S" in SQL stood for "Standard" :P As an aside, I also love the fact he presumed the author of usql - someone who has been reverse engineering undocumented drivers to bring support to Go(lang) - was unaware of what the name of his own tool and the language it exposes stood for, is just laughable.