| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
schema format.
Additionally:
* It changes `purge` task on `sqlite3` adapter to recreate database file, to
be consistent with other adapters.
* Adds `purge` step when loading from `schema.rb`
|
|
|
|
|
| |
rather than YAML.load(File.read(path)). YAML.load_file is also used in
guides/rails_guides/helper.rb since 2011, the only other precedent I could find.
|
|
|
|
| |
Closes #13625
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Move check from generated helper to test_help.rb, so that all
applications can benefit
* Rather than just raising when the test schema has pending migrations,
try to load in the schema and only raise if there are pending
migrations afterwards
* Opt out of the check by setting
config.active_record.maintain_test_schema = false
* Deprecate db:test:* tasks. The test helper is now fully responsible
for maintaining the test schema, so we don't need rake tasks for this.
This is also a speed improvement since we're no longer reloading the
test database on every call to "rake test".
|
|
|
|
|
|
| |
Warning:
DEPRECATION WARNING: Passing a string to ActiveRecord::Base.establish_connection for a configuration lookup is deprecated, please pass a symbol (:development) instead.
|
|
|
|
|
|
|
|
|
| |
This commit also cleans up the rake tasks that were checking
for DATABASE_URL in different places.
In fact, it would be nice to deprecate DATABASE_URL usage in the long
term, considering the direction we are moving of allowing those in .yml
files.
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 22f80ae57b26907f662b7fd50a7270a6381e527e.
See
https://github.com/rails/rails/commit/22f80ae57b26907f662b7fd50a7270a6381e527e#commitcomment-4640676
Conflicts:
activerecord/CHANGELOG.md
|
|\
| |
| |
| |
| |
| |
| | |
Explicitly exit with status "1" for create and drop task failures
Conflicts:
activerecord/CHANGELOG.md
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* A non-zero exit status allows subsequent shell commands to be chained
together such as: `rake db:reset test:prepare && rspec && cap deploy`
(if you're feeling brave :)
* Any exceptions raised during the `create` and `drop` tasks are caught
in order to print a "pretty" message to the user. Unfortunately doing
so prevents rake from aborting with a non-zero exit status to the shell.
* Therefore we re-raise the exceptions after the "pretty" message and
re-catch them in the task.
* From the task we explicitly exit with a non-zero status. This method
was chosen (rather than just letting rake fail from the exception) so
that the backtrace is suppressed and the output to stderr is
unchanged.
* Update activerecord CHANGELOG
|
| |
| |
| | |
Same as 4d4ff531b8807ee88a3fc46875c7e76f613956fb
|
| |
| |
| |
| | |
whitespace in it
|
|/ |
|
| |
|
|
|
|
| |
3rd-party.
|
|
|
|
| |
3rd-party.
|
|
|
|
| |
3rd-party.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
It's simpler to assume that passed env is just a string without any
extensions, especially when DatabaseTasks are intended to be used also
without rails.
|
| |
|
|
|
|
|
|
| |
This is a public class, which could be used directly in order to allow
easier database management. Now it also contains settings, which will be
used by databases.rake.
|
|
|
|
|
|
| |
This will allow to set fixtures path in global config easier, it should
be not needed to use FIXTURES_PATH every time user wants to load
fixtures.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| | |
|
|/ |
|
| |
|
| |
|