Toward A Database URI Standard | Hacker News Reader

Toward A Database URI Standard

theory.so

46 pointsmariuz25 comments

Everything was great here until the post suggested...let's have two formats? All the examples mentioned (one of which is my own) use a strict RFC-1738 style, and the "//" is required, including for filesystem paths. RFC-1738 already provides the spec and as all the linked examples illustrate, it's all we need. Why the second format omitting the so-called "authority part"?

edit: wow rfc1738 is like two rfcs ago, we're up to rfc3986 now. rock!

For sqlite, there isn't really a host name. It's just a file path. What would that look like if you could only use the first format?

Would it not be

file:///path

as per RFC 1738?

I guess that could work.

  file:///path?foreign_keys=ON;journal_mode=WAL

I would be okay with having just one one, though in principal I don't see much difference.

The different examples are all pretty much just different ways of writing the same thing. And then another different way of writing the same thing is presented, with "db:" prepended. Huh.

The only thing that is substantially different between any of these is the engine/protocol/adapter/whatever section. Perhaps that field should always refer to the protocol type and not the driver, but I consider that problem pretty negligible.

The db: prefix must (according to the article) always be there. What he's describing is the URI part, which follows RFC 3986. It's not two formats, just one: db:<URI>.

Yes, but for convenience (and compatibility with other proposals), I think it would be okay for a given implementation to recognize well-known engines and treat them as valid DB URIs even in the absence of a <code>db:</code> prefix. I've added notes to the <a href="https://github.com/theory/uri-db">documentation</a> to that effect.

Publish an RfC.

Yes, this. It's the proper way to communicate standards in the internet community.

I'd be much more comfortable following an RFC than a blog post.

This blog post is soliciting feedback on the general idea before I go and do the work of submitting a formal RFC. For all I know, someone could have shot it down. Just think of this as step 1 toward the development of an RFC.

Publishing an RFC is not that straightforward because of the formatting requirements. In any case, whether you go on a blog or publish a draft RFC, you WILL get shot down a lot. Part of the territory.

If I were you I would contact some people who have done RFCs before and ask their advice. Contact the Applications Area directors at the IETF and ask for advice. Barry Leiba <barryleiba@computer.org> Pete Resnick <presnick@qti.qualcomm.com> If they think that this work belongs in a new WG then they can help you get it set up.

Thank you, I will do that!

So what you're saying is, this blog post is a... puts shades on request for comments?

YEEEEEEEEEAAAAAAAHHHHHHH!

(please don't hurt me)

Sounds great! Let me know if you need any help with that process.

Will do. Is this thread a good place to get back to you guys if/when a WG is set up? Would likely be after the US holidays…

Could Heroku be used for some guidance on this topic? They provide database URLs[1], and have built stuff like dj-database-url[2] to implement them.

[1]: https://devcenter.heroku.com/articles/heroku-postgresql [2]: https://github.com/kennethreitz/dj-database-url

That was one of the precedents I looked at, but I should definitely touch base with Heroku to see if they have any suggestions, too.

This is something that really should be done under the auspices of the IETF. Folks interested in this should ask the IETF to set up a WG and they should include a generic network database protocol (or protocols) as one of the goals. Some people will just want to work out the URI issue but others will be interested in seeing through the larger issues.

There is probably more than these options that you want to serialize into the URI. For example the MySQL client can be configured with an encoding charset, or maybe you want to specific the size of the connection pool ?

isn't that something that should go in the 'query', e.g.:

    db:mysql://user@host/db?encoding_charset=utf8

I'm sure it will technically work but is it still really an URI ? URI is meant for resource identification. Here connection details are crammed into the 'query' to access a DB.

It might be better to come up with another "one-line string" format that's better adapted for DB connection, is regular and more easily parsed.

What might such a thing look like?

Part of the reason I like my proposal is because it's just a generic server URI, so deeply familiar to nearly all developers. And for that format, it's the GET query string that allows for additional parameters.

Relevant xkcd: http://xkcd.com/927/

the difference is that there is _no_ standard so far...

Reply on news.ycombinator.com