DATABASE_URL should take precedence over database.yml

[jnicklas]

ActiveRecord/Rails prefers the DATABASE_URL environment variable over the configuration in database.yml, if both are set the environment variable is used.

IMO sequel-rails should match this behaviour.

Being able to override the config via an environment variable is very useful for a number of reasons. It makes it easy to fire off a debugging session against a different database, for example I could load a db dump into a different database and then fire up a DATABASE_URL=... rails server and don't have to mess with the configuration, and don't have to throw away my dev database and can easily switch back.

Another reason is that services like Heroku configure the database via this environment variable. When using their new CI service for example, it's pretty annoying to get the database connection to use the local database in development, but use the environment variable for CI.

[JonathanTron]

Hi @jnicklas, thanks for raising the issue.

We're indeed using what's in the database.yml file first, and only if there's no url in there we're setting it from ENV["DATABASE_URL"] (see: https://github.com/TalentBox/sequel-rails/blob/master/lib/sequel_rails/configuration.rb#L76-L77).

Then later when calling Sequel.connect, we're using the url if it's there otherwise just forwarding the config as is (see: https://github.com/TalentBox/sequel-rails/blob/master/lib/sequel_rails/configuration.rb#L76-L77)

There's multiple issue there:

1. We're not constructing an URL from the params in the database.yml file, nor trying to extract information from URL to what would have been equivalent params.
2. When we have an URL, we're using it, but we're also sending all the params to the Sequel.connect method. This means if your config contains keys which are already in the URL, the values will act as override of the URL ones.

Not sure what's the best way to tackle them.

For 1, If I recall correctly (it's been more than 3 years I checked), there's a good chunk of code in Rails/AR, specific to each supported database to handle the conversion from URL to connection params, I'm really not fond of trying to do such thing. I would prefer to let Sequel handle most of that itself.

For 2, this allows to easily pass specific database connection options to Sequel.connect, without having to specifically handle them in sequel-rails.

I'm open to propositions to better handle those cases.

[JonathanTron]

To be fair, we're in fact already constructing url to handle jdbc and do (see: https://github.com/TalentBox/sequel-rails/blob/master/lib/sequel_rails/db_config.rb)...

I'm wondering how much people are relying on the combo of DATABASE_URL from env + merge other option from config...

[JosephHalter]

When using their new CI service for example, it's pretty annoying to get the database connection to use the local database in development, but use the environment variable for CI.

I think the best practice is to put database.yml (used in development) in .gitignore

[adamgotterer]

+1 for this feature. I also expected DATABASE_URL to override the database.yml config values and mimic how AR works in rails.

[jacquescrocker]

Bringing this up again. Really helpful for heroku deploys

[benkoshy]

@jacquescrocker hi Jacques wondering if you have a very basic hello world rails app deployed to heroku - i'm having trouble getting heroku to connect to the sequel database and run some basic migrations. any pointers would be much appreciated. chrs

[benkoshy]

I've got a basic one up and running on heroku, with instructions: https://github.com/BKSpurgeon/testing_in_sequel

For anyone who comes across this thread in the future and is interested.

Hope it helps!

[michaelfranzl]

When we have an URL, we're using it, but we're also sending all the params to the Sequel.connect method. This means if your config contains keys which are already in the URL, the values will act as override of the URL ones.

I would venture to say that the expectation nowadays is the opposite, i.e. that environment variables are overrides; because modifying source code files (like database.yml) from scripts is a lot more cumbersome than setting environment variables.

And, Rails comes with a database.yml file, which precludes usage of DATABASE_URL, which is why I would say that sequel-rails should behave in the other way.

What was the reason behind this decision? If there was none, wouldn't the fix be to just forward the plain URL to Sequel.connect, without the params?

sequel-rails/lib/sequel_rails/configuration.rb

Line 60 in 1babc13

::Sequel.connect normalized_config['url'], SequelRails.deep_symbolize_keys(normalized_config)

to

::Sequel.connect normalized_config['url']

[michaelfranzl]

For containerized Rails applications, with this issue present, the only way to make DATABASE_URL fully effective is by putting config/database.yml into .containerignore or .dockerignore.