Enable CockroachDB in CI and update documentation

[kibertoad]

No description provided.

[glensc]

you sure it should be comma separated, previous ones were space separated

[Frank-D]

hi @kibertoad,
does that mean the new 'CockroachDB' dialect is ready to be used (or at least tested) by the community?

I see in latest change logs (0.95.12 at time of this writing) the following:

New dialect: CockroachDB #4742

But at the same time, I see in the installation instructions the below:

If you want to use CockroachDB or Redshift instance, you can use the pg driver.

So I'm wondering if the doc will get updated, and if I can already reference the new crdb dialect (or driver, a bit confused with the terminology here to be honest, between the new crdb dialect, and the pg driver..), and if so, how exactly/what exact string I need to use in the knex config to leverage that new crdb dialect?

thanks!

[kibertoad]

@Frank-D Both are correct. You should specify "cockroachdb" as a dialect, and have pg available as a dependency. crdb doesn't have a driver of its own. And yes, it is ready to be used.

I will revise readme to see if I can make it less confusing.

[Frank-D]

Wow, lightning fast response @kibertoad !

Alright, so if we were to summarize super briefly the installation and configuration of such setup, would that be around those below lines?

Installation :
(as seen on your site here):
1- npm install knex --save
2- npm install pg --save

Configuration:
(similar to what can be seen on your side here under the "...PostgreSQL adapter to connect a non-standard database..." section, but this time with a small change to the client? Not sure if changing the client is what you meant when suggesting to plug in the new 'cockroachdb' dialect...in knex world, does such 'client' == 'dialect', or the 'client' is really the 'driver', and that should remain 'pg' here in this case, and plugging the crdb dialect should be done/configured differently?)

Note: The database version can be added in knex configuration, when you use the PostgreSQL adapter to connect a non-standard database.

const knex = require('knex')({
  client: 'pg',  *** Replace with 'cockroachdb' instead? else, where should we configure this new 'cockroachdb' dialect?
  version: '7.2',  *** Is that version still needed, when using the 'cockroachdb' dialect/client? I believe it can now be dropped?
  connection: {
    host : '127.0.0.1',
    port : 3306,
    user : 'your_database_user',
    password : 'your_database_password',
    database : 'myapp_test'
  }
});

[kibertoad]

Sample Cockroachdb config:

  cockroachdb: {
    client: 'cockroachdb',
    connection: {
      adapter: 'cockroachdb',
      port: 26257,
      host: 'localhost',
      database: 'test',
      user: 'root',
      password: '',
    },
    pool,
    migrations,
    seeds,
  },

[intech]

@Frank-D I ask you to take into account the given list

[Frank-D]

@kibertoad, thanks much appreciated. Any reason why the 'cockroachdb' client can't hide setting the adapter (which takes the same value 'cockroachdb') internally, rather than having to provide the adapter in the knex.connection config? Otherwise, much appreciated!

@intech, 100%, thanks. Just to be sure (since that page/list doesn't contain any explanation), are we saying that this is the list so far that has been identified in terms of known gaps between postgres and cockroachdb, that will need to be taken care over time in this new 'cockroachdb' knex dialect (..so items unchecked are not expected to work/be supported as of now)? ..and so, once an item of that list is checked, it means, a fix was provided, either as part of a given knex crdb dialect version (wondering how we'll know which item comes in which knex version..), or perhaps the fix may be done directly in crdb for some items...is that how we should read this list?)

thanks

[kibertoad]

@Frank-D It might actually be redundant, I'll need to check.

[intech]

@Frank-D If you are using cockroach then I suppose because of its peculiarities. And they are not backward compatible with the pg dialect. It extend it with additional syntax. Therefore, the transition from pg to crdb will not be any different, but if you are already using some of the cockroach features, then you should check against this list.
I will try to keep it up to date at all times and mark the versions in which it appears (thanks for the hint).

[Frank-D]

Thanks @intech, that's great.

And to one of your point, I am actually not using any of their crdb specific features (at least not yet), and I selected them not because of their specific features, but rather because of their hosting offerings (especially, their new crdb "serverless" offering, which seems to be great to start with, compared to many other db cloud hosting offerings I looked at..), or else, I would have probably stick with some very standard native postgres db and would have avoided those challenges! But cloud hosting/offering has become over the years almost as important as the product features themselves, if not, sometimes, more important, based on your scenarios etc).

And so, short to mid term at least, I'm not necessary planning on falling into any of those limitations, but who knows, fingers crossed! For time being, I'm just really happy that you guys have spent all this work to make such initial crdb support, that's really great news for the community, giving them more options! ✌️