| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
for an unknown adapter
|
|
|
|
|
|
|
|
|
|
| |
When running tasks such "rake db:setup", instead of showing messages
like "db_development already exists", it was showing a big stack trace
and a message "Couldn't create database for ..." with the configuration
options, a very confusing message with a big trace.
This brings back the functionality present in 3-2, showing the same
message.
|
|
|
|
|
|
|
|
|
|
|
|
| |
- added tests to confirm establish_connection uses DATABASE_URL and
Rails.env correctly even when no arguments are passed in.
- updated rake db tasks to support DATABASE_URL, and added tests to
confirm correct behavior for these rake tasks. (Removed
establish_connection call from some tasks since in those cases
the :environment task already made sure the function would be called)
- updated Resolver so that when it resolves the database url, it
removes hash values with empty strings from the config spec (e.g.
to support connection to postgresql when no username is specified).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
by Active Support)
Selecting which key extensions to include in active_support/rails
made apparent the systematic usage of Object#in? in the code base.
After some discussion in
https://github.com/rails/rails/commit/5ea6b0df9a36d033f21b52049426257a4637028d
we decided to remove it and use plain Ruby, which seems enough
for this particular idiom.
In this commit the refactor has been made case by case. Sometimes
include? is the natural alternative, others a simple || is the
way you actually spell the condition in your head, others a case
statement seems more appropriate. I have chosen the one I liked
the most in each case.
|
|\
| |
| | |
Allow to register database tasks from different adapters
|
| | |
|
|/ |
|
| |
|
| |
|
|
|
|
|
| |
In a similar vein to Pat's work on create, drop etc, the db:charset
task is now a one liner in databases.rake
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Now isn't that better?
And yes, I know that private has no impact on class methods - it's a visual distinction, not a technical one.
|
| |
|
| |
|
| |
|
|
Minimal implementation that supports db:create SQLite replacement
|