| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Closes #8079.
I had to rework some of the tests because the mock allowed any arguments
for `connection.exeucte`. I think this is very dangerous as there could
anything be executed without the tests noticing it.
|
|
|
|
|
|
|
|
| |
Closes #9518.
The rake task used to fail silently and left an empty `structure.sql`.
It's confusing for users to get to the root of the problem.
The warning message tells them where to look.
|
|
|
|
| |
for an unknown adapter
|
|
|
|
|
|
|
|
|
|
| |
exception
We were previously rescuing "nil" when no exception class was found.
This does work in 1.9.3, but does not in 2.0, raising an exception
asking for a class or module to be given to the rescue clause.
Thanks @yahonda for catching this.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
set utf8_unicode_ci collation on latin1 table.
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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).
|
|
|
|
| |
charset but encoding.
|
| |
|
|
|
|
| |
The previous implementation had the strange requirement that db/structure.sql contain only CREATE TABLE sql statements, one per table, separated by double newlines. SQLite3 and PostgreSQL database tasks, on the other hand, simply spawn 'sqlite3' and 'psql' binaries to load the file directly. The new implementation follows this and attempts to respect all current MySQL configuration settings.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|