Currently a developer can pass in a YAML configuration that fully specifies connection information:
```
production:
database: triage_production
adapter: password
pool: 5
```
They can also pass in a string that specifies a connection URL directly to an environment key:
```
production: postgresql://localhost/foo
```
This PR allows the use of both a connection url and specifying connection attributes via YAML through the use of the "url" sub key:
```
production:
url: postgresql://localhost/foo
pool: 3
```
This will allow developers to inherit Active Record options such as `pool` from `&defaults` and still use a secure connection url such as `<%= ENV['DATABASE_URL'] %>`. The URL is expanded into a hash and then merged back into the YAML hash. If there are any conflicts, the values from the connection URL are preferred.
Talked this over with @josevalim
Document the internal interfaces of `ConnectionSpecification::Resolver`
Change method name from `config` to `env` to better match the most common use case.
FIXTURES_PATH has a bit different case than DatabaseTasks.fixtures_path,
which was added along with deprecation. A use case for FIXTURES_PATH
could be loading fixtures from a different directory just for a given
test run. The implementation is fairly simple, so leaving it as it is
won't hurt.
In #5337 we forced the path encoding to ASCII-8BIT to prevent static
file handling from blowing up before an application has had chance to
deal with possibly invalid urls. However this has a negative side
effect of making it an incompatible encoding if the application's
public path has UTF-8 characters in it.
To work around the problem we check to see if the path has a valid
encoding once it has been unescaped. If it is not valid then we can
return early since it will not match any file anyway.
Fixes#13518
Rubinius has problems with bundling when shared gems are disabled (ie.
when --path or --deployhment is used). There is no real reason to
install it with --path on TravisCI, so I'm dropping it.
The contract of blank? and present? was in principle to return Object, as we
generally do, the test suite and description was consistent with that, but some
examples had comments like "# => true".
This cannot be unclear, we either fix the examples, or update the contract.
Since users may be already assuming singletons due to the examples and the fact
that they were returned before 30ba7ee, the safest option seems to be to revise
the contract and the implementation of String#blank?
The motivation for 30ba7ee was to improve the performance of the predicate, the
refactor based on === is on par regarding speed.
With this commit we start documenting return types using YARD conventions. We
plan to document return types gradually.
Without this, the original record's values won't get saved, since the partial insertions support (144e8691cb) checks for changed values and thinks there are none.
Define Minitest::Test in case we are running the gist under Minitest 4
and avoid relying on MiniTest::Unit::TestCase to avoid displaying
warning on version five.
[ci skip]
