Require explicit db name when connecting

[1st1]

With the new connect API a user can connect to EdgeDB just by specifying an instance name. The database name isn't required and is set by default. I think that's a bad idea that only complicates things unnecessarily:

• Many users won't know the name of the default DB.
• Many users won't understand that instances can have multiple DBs in them.
• When using a REPL we show the DB name in the prompt. We'll do the same in our cloud control panels and admin panels. If users don't get accustomed to the idea that EdgeDB actually connects to a particular DB and not "just to an instance" they can get confused.

Therefore, I propose to always require the DB name to be specified with the following API:

1. connect() methods will continue to support DSN strings, where a DB name comes after the first /, as in edgedb://edgedb@localhost/DBNAME

2. connect() methods can also accept an instance name which would come with an explicit DB name, as in: INSTANCE/DBNAME.

3. And I also propose to change the default DB name to a simple "db".

[ambv]

Regardless of implicit defaults, we need to have a way to enable users to connect to a non-default database on a given instance.

For this purpose, the slash syntax is another variant of a structured string that would have to be understood by the user, escaped by the user, parsed on our side. I prefer the clarity of a DSN.

As for implicit defaults, I think with cloud panels, Studio, and the CLI, a user who doesn't know about database names will learn about them from the tools. As you said, those tools expose the name already.

I like the current approach of connecting with the default database implicitly. I don't have a horse in the race for the best name for the default database, "db" is short and cute, I like it.

[1st1]

For this purpose, the slash syntax is another variant of a structured string that would have to be understood by the user, escaped by the user, parsed on our side. I prefer the clarity of a DSN.

Full DSN is very verbose. If the only thing you want is to connect to a different DB in an instance we currently want the user to do this:

connect('instance', database='other_db')

And then there are other downsides to having a default DB.

Take a look for @elprans' proposal at #1683. He proposes there to have an object to store all instance config in, let's call it InstanceConfig here. The idea is that you can simply connect to an instance by name, as in connect('instance') or construct an object explicitly:

instance = edgedb.InstanceConfig(host='...', port='...', password='...')
conn = edgedb.connect(instance)

The beauty of this approach is that you can configure an InstanceConfig in one place in your code and then use it to configure regular connections and connection pools (as in pool = await edgedb.pool(instance)).

But what if you want to configure a custom non-default DB? You'd need to:

instance = ('instance', 'customdb')
# or
instance = (
  edgedb.InstanceConfig(host='...', port='...', password='...'),
  'custom_db
)

and then

conn = edgedb.connect(*instance)

So IMO, DB name must be a part of instance config. And if it has to be and we can either specify an instance by name or by creating a config object, I propose the instance name to include DB name too.

I like the current approach of connecting with the default database implicitly.

I'd like to hear more substantive motivation for having a default DB than simple "like" or "dislike". I for one see no benefit of having a default DB; even MongoDB educates its users about different DBs and requires a DB name when you connect to it. But I've listed quite a number of reasons why instance names should include a DB name and if we make them to do that there's little motivation to have a default one.

[tailhook]

Well, just few months ago we though that users will not use multiple databases too much. This is even more true if we say that each project will have it's own instance (because each project should manage their own current version and upgrade independently).

I'm not strongly opposed to required database name, but I'm opposed to instance/name string. This is just another DSL, so just for connection string we have two DSLs to learn and a full builder interface.

[tailhook]

Also does it mean that calling repl is now as easy as edgedb -Imyproj -ddb?

[1st1]

Also does it mean that calling repl is now as easy as

I thought more along the lines of edgedb myproj/db but maybe it's not a good idea because it conflicts mentally with FS paths.

Well, just few months ago we though that users will not use multiple databases too much. This is even more true if we say that each project will have it's own instance (because each project should manage their own current version and upgrade independently).

That's still true. But I'm not sure how not having a default DB breaks any of that. Literally all DBs require it to be specified explicitly at the connection time.

I'm not strongly opposed to required database name, but I'm opposed to instance/name string. This is just another DSL, so just for connection string we have two DSLs to learn and a full builder interface.

I'm thinking about this slightly differently: it's always a DSN. Just when you need to specify host/port/etc you start with edgedb:// ... /DBNAME, but you can use instance as a shortcut with instance/DBNAME.

[RobertoPrevato]

• I agree that implicit default can be confusing; when I started several years ago with SQL Server I got confused at the beginning about the default instance name of SQLExpress; but I blame this more on my inexperience than SQL Server
• Caring about users who might get confused and think that a DB Server equals, or supports, a single DB instance is correct, but I think it is sufficient to make it clear in documentation. I wouldn't change code API to accommodate the needs of most inexperienced users.
  -- my rationale here is: our target are DB users, and most DB users are aware that DB Servers usually support more than one instance (e.g. I don't expect a car manufacturer to tell me I shouldn't shut my fingers inside the car's doors)
• I personally prefer a verbose and explicit API over a terse one; so I don't mind:

connect('instance', database='other_db')

I wouldn't even mind:

connect(server='instance', database='other_db')

However this looks clear to me, too:

connect('instance/dbname')

• When using tools that interact with a DB Server, I expect having to specify a DB name, so having to write database= or -db doesn't feel wrong

[RobertoPrevato]

My comments above are about users' experience - I wrote in the first person thinking as a user. On the technical side, I agree with Łukasz and Paul about "instance/dbname". I vote for not changing API for this reason, but if change is needed, I vote for a verbose api. My two cents.