Extract common database defaults; better use of YAML

[bf4]

Use the power of YAML in the database configurations to better express adapter concerns versus environment concerns. Also see https://github.com/bf4/yaml_resources/blob/master/recipes/rails_database_configuration.md

[bf4]

Let me know if your'e interested in changes in the explanatory text, or if you want more of the common language across the different templates extracted or abstracted.

[bf4]

It would be really super great if when a rails core member reviews this s/he assigns someone to it...

[senny]

/cc @fxn

[bf4]

@senny @fxn Let me know if you'd like me to rebase this off of master

[bf4]

@senny @fxn @tenderlove thoughts?

[fxn]

On one hand, in my experience it is quite common that different environments share some subset of the configuration. In that sense this edit could be statistically convenient (so to speak).

But on the other hand, it is a smell for me that we need comments to explain to users what's that. The comments are justified because this YAML feature is maybe not so widely known, but that defeats the whole simplification goal in my view, you've only moved the problem. There's redundancy in the current generated YAML, but it is trivial to understand, needs no comments.

So while I sympathize with the proposal, I am not really positive about it.

[bf4]

@fxn thanks for following up.

I wrote this PR because I find myself extracting common configs on every project. This was also featured in Rails Recipe and in a recent post by EnvyLabs also sent in the RubyWeekly. So, there is definitely traction for the idea.

I see the comments as furthering an understanding of a data serialization format that's been popular in Ruby since before _why wrote libsyck in 2003.

I think there is a need to better understand that YAML is more than JSON, and to make use of that for greater developer happiness.

Would you like, perhaps, the PR implemented differently, to be just a comment, but no code change, or perhaps no comments?

[fxn]

@bf4 from my perspective, the PR would be better without meta comments about YAML, just refactor. It can be argued that if your config is YAML, you have to know YAML.

[bf4]

I'll remove, amend, and force push later tonight. Thanks for your attention

[bf4]

@fxn Updated to remove comments and rebased off of master

[fxn]

Good to go, thanks for working on this!

[bf4]

And thanks for following up @fxn!

[RKushnir]

While dev and test databases often share their settings, production, from my experience, usually has different host and credentials. So besides getting a more cryptic config, there doesn't seem to be any other advantages.

[fxn]

Your production config will just override a couple of the keys typically.

[bf4]

@fxn Perhaps I should add information on this to the guides.

@RKushnir is there anything in particular you'd find helpful to be documented? Examples?

[fxn]

@bf4 in principle this change wouldn't need extra documentation in my opinion (other than sync'ing examples to match the file, if there were any).

[bf4]

Followed by #27611