aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/lib/active_record/railties
Commit message (Collapse)AuthorAgeFilesLines
* Make `db:migrate:status` to render `1_some.rb` format migrate files.yui-knk2015-11-021-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `1_valid_people_have_last_names.rb` and `20150823202140_create_users.rb` are valid migration file name. But `1_valid_people_have_last_names.rb` is rendered as `********** NO FILE **********` when `rake db:migrate:status`. Fix to this bug, this commit includes * define some API private methdos and a Constant `match_to_migration_filename?`, `parse_migration_filename`, and `MigrationFilenameRegexp` * use these methods in `db:migrate:status` task Example: These files are in `db/migrate` * 1_valid_people_have_last_names.rb * 20150819202140_irreversible_migration.rb * 20150823202140_add_admin_flag_to_users.rb * 20150823202141_migration_tests.rb * 2_we_need_reminders.rb * 3_innocent_jointable.rb we can migrate all of them. Before ```shell $ bundle exec rake db:migrate:status ... Status Migration ID Migration Name -------------------------------------------------- up 001 ********** NO FILE ********** up 002 ********** NO FILE ********** up 003 ********** NO FILE ********** up 20150819202140 Irreversible migration up 20150823202140 Add admin flag to users up 20150823202141 Migration tests ``` After ```shell $ bundle exec rake db:migrate:status ... Status Migration ID Migration Name -------------------------------------------------- up 001 Valid people have last names up 002 We need reminders up 003 Innocent jointable up 20150819202140 Irreversible migration up 20150823202140 Add admin flag to users up 20150823202141 Migration tests ```
* fix typo in `db:purge` description [ci skip]yuuji.yaginuma2015-10-281-1/+1
|
* Fix out of sync commentBrandon Conway2015-09-231-1/+1
| | | It appears that as of version 4 the `db:test:prepare` task no longer depends on the `abort_if_pending_migrations` task, which leaves this comment out of sync.
* introduce `conn.data_source_exists?` and `conn.data_sources`.Yves Senn2015-09-221-1/+1
| | | | | | | | | | | | | | | | | These new methods are used from the Active Record model layer to determine which relations are viable to back a model. These new methods allow us to change `conn.tables` in the future to only return tables and no views. Same for `conn.table_exists?`. The goal is to provide the following introspection methods on the connection: * `tables` * `table_exists?` * `views` * `view_exists?` * `data_sources` (views + tables) * `data_source_exists?` (views + tables)
* Merge pull request #21529 from rngtng/move-migrations-paths-to-database-taskYves Senn2015-09-091-7/+7
|\ | | | | | | Use `ActiveRecord::Tasks::DatabaseTasks.migrations_paths` explicit for db tasks
| * Use `ActiveRecord::Tasks::DatabaseTasks.migrations_paths` instead of ↵Tobias Bielohlawek2015-09-071-9/+8
|/ | | | `Migrator.migrations_paths`
* [ci skip] Replace `AR` with `Active Record` in task descyui-knk2015-09-071-1/+1
| | | | | Many user look `desc` of rake task and they are not familiar with `AR`. `Active Record` is more familiar word.
* follow-up to 2183caa, always reenable the task. #20743Yves Senn2015-06-301-3/+3
|
* `dump_schema_after_migration` applies migration tasks other than db:migrateYves Senn2015-06-301-9/+12
| | | | | | | | | | | | | Closes #20743. The task `db:_dump` now only dumps the schema if `ActiveRecord::Base.dump_schema_after_migration` is true. This has effects: - `db:migrate:up` - `db:migrate:down` - `db:forward` - `db:rollback`
* Fix descriptions of databases.rake [ci skip]Mehmet Emin İNAÇ2015-06-171-11/+11
| | | | revert create and drop task descriptions
* Small refactor on db:resetArthur Neves2015-06-151-4/+1
| | | | | | | | | | | | db:reset should not prematurely load the environment, so, for instance, if there is any initializer that touches th DB, it will not touch that before droping it. Also this makes the code simpler. This changed was made back in 15fb4302b6ff16e641b6279a3530eb8ed97f2899 , not sure why. But I am pretty much sure we should do it like this, as drop and setup should load its dependencies tasks if necessary.
* make sure to load_config for db:abort_if_pending_migrationsSteven Davidovitz2015-05-041-1/+1
|
* Revert "Merge pull request #17920 from ↵Yves Senn2015-04-271-1/+1
| | | | | | | | | | | | | | | calebthompson/dont-rely-on-environment-task-for-schema-load" This reverts commit 08ff4ccbbb3fb143a02e6752efb974a4bcfcd3bb, reversing changes made to 6c9ed6dbc62450cdb87559afd15798305e069146. Caused by #17920. Closes #19545. This patch introduced regressions because initializers were no longer loaded. Specifically missing inflections result in broken restores of the database.
* Don't invoke sql_runtime if logger is not set to infoeileencodes2015-04-041-1/+1
| | | | | | | | | `sql_runtime` was getting invoked even when the logger was set to fatal. This ensures that does not happen by checking that the logger is set to info level before logging the view runtime. This reduces the number of times `sql_runtime` is called for integration tests with a fatal logger from 6 to 2.
* Schema creation doesn't load the appTamir Duberstein2015-02-111-1/+1
|
* Use `SCHEMA` instead of `DB_STRUCTURE` for specifiying structure file.Dieter Komendera2015-01-081-3/+3
| | | | | `rake test:load_structure` already uses `SCHEMA` and there's no need to maintain two different env vars.
* Replace deprecated `#load_schema` with `#load_schema_for`.Yves Senn2014-12-231-2/+2
|
* Remove environment dependency for db:schema:loadCaleb Thompson2014-12-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | All of the behavior :environment was giving (that db:schema:load needed) was provided as well with :load_config. This will address an issue introduced in https://github.com/rails/rails/pull/15394. The fact that db:schema:load now drops and creates the database causes the Octopus gem to have [an issue](https://github.com/tchandy/octopus/issues/273) during the drop step for the test database (which wasn't happening in db:schema:load before). The error looks like: ActiveRecord::StatementInvalid: PG::ObjectInUse: ERROR: cannot drop the currently open database : DROP DATABASE IF EXISTS "app_test" Because of the timing, this issue is present in master, 4-2-*, and 4.1.8. A note to forlorn developers who might see this: "Additionally" in a commit message means you should have a separate commit, with a separate justification for changes. Small commits with big messages are your friends.
* Pass symbol as an argument instead of a blockErik Michaels-Ober2014-11-291-1/+1
|
* bring back `db:test:prepare`.Yves Senn2014-11-251-5/+5
| | | | | | | | | | | | | | | This reverts deprecations added in #13528. The task is brought back for two reasons: 1. Give plugins a way to hook into the test database initialization process 2. Give the user a way to force a test database synchronization While `test:prepare` is still a dependency of every test task, `db:test:prepare` no longer hooks into it. This means that `test:prepare` runs before the schema is synchronized. Plugins, which insert data can now hook into `db:test:prepare`. The automatic schema maintenance can't detect when a migration is rolled-back, modified and reapplied. In this case the user has to fall back to `db:test:prepare` to force the synchronization to happen.
* Add comment to point out String#[] is intentionalAndrew White2014-11-021-0/+1
|
* Revert "Replace String index juggling with Pathname goodness in ↵yuuji.yaginuma2014-11-021-1/+1
| | | | | | | | db:fixtures:load" This reverts commit 482fdad5ef8a73688b50bba3991dd4ef6f286edd. Fixes #17237.
* Use Hash#each_key instead of Hash#keys.eachErik Michaels-Ober2014-09-291-1/+1
| | | | | | Hash#keys.each allocates an array of keys; Hash#each_key iterates through the keys without allocating a new array. This is the reason why Hash#each_key exists.
* schema rake tasks are specific about the configuration to act on.Yves Senn2014-08-061-10/+4
| | | | | | | | | | The rake tasks and the `DatabaseTakss` adapter classes used to assume a configuration at some places. This forced the rake tasks to establish a specific connection before calling into `load_schema`. After #15394 this started to cause issues because it could `purge` the wrong database before loading the schema.
* Add ActiveRecord::Tasks::DatabaseTasks.migrateJack Danger Canty2014-07-311-4/+1
| | | | | | This extracts the logic that was embedded in a Rake task into a static method. Bonus: the first test for `rake db:migrate`
* Use AR::SchemaMigration.table_exists? call instead of longish AR::Base...etc,etcViktar Basharymau2014-06-271-1/+1
|
* Extract AR::SchemaMigration.normalized_versions methodViktar Basharymau2014-06-271-2/+1
|
* db:migrate:status refactoring: Rewrite hand-crafted SQL query with ↵Viktar Basharymau2014-06-271-1/+1
| | | | ActiveRecord#pluck
* Use Array#flat_map and Array#grep in db:migrate:status taskViktar Basharymau2014-06-271-10/+10
| | | | It allows the code to be more declarative and elegant.
* Add explaining variables to db:migrate:statusViktar Basharymau2014-06-271-2/+2
|
* Replace String index juggling with Pathname goodness in db:fixtures:loadViktar Basharymau2014-06-271-1/+1
|
* db:fixtures:load refactoring: remove unnecessary loopViktar Basharymau2014-06-271-3/+1
| | | | | `ActiveRecord::FixtureSet.create_fixtures` can accept an array of fixture_files.
* Extract `fixture_files` variable in fixtures:load rake taskViktar Basharymau2014-06-271-1/+7
|
* Replace a bit of cryptic code in fixtures:load rake task with plain stupid RubyViktar Basharymau2014-06-271-1/+5
|
* Get rid of duplication in db:fixtures:{identify,load}Viktar Basharymau2014-06-271-11/+2
|
* db:fixtures:{identify,load} tasks respect AR::Tasks::DatabaseTasks.rootViktar Basharymau2014-06-271-2/+2
| | | | | | | Before this commit, if `ENV['FIXTURES_PATH']` was set, then `Rails.root` was used, otherwise the app used `ActiveRecord::Tasks::DatabaseTasks.root`. Now it is consistent.
* Simplify complex code in databases.rakeViktar Basharymau2014-06-271-2/+2
|
* add `bin/rake db:purge` task to empty the current database.Yves Senn2014-06-171-0/+11
|
* `bin/rake db:migrate:status` works with legacy migration numbers.Yves Senn2014-06-061-3/+4
| | | | | | | The migration numbers were normalized different ways. This left the task output in an inconsistent state. Closes #15538.
* rake railties:install:migrations respects the order of railtiesArun Agrawal2014-05-271-1/+1
| | | | This PR fixes #8930 and some stuff from #8985
* Return a non zero code when db has never been setup on statusPaul B2014-05-071-2/+1
|
* make `db:structure:load` listed with `rake -T`Greg Molnar2014-05-021-1/+1
|
* Replace trivial regexp with string or index, twice as fastKelley Reynolds2014-03-281-1/+1
|
* only dump schema information if migration table exists. Closes #14217Yves Senn2014-03-201-1/+2
|
* Merge pull request #14048 from pcreux/better-error-message-db-migrate-downCarlos Antonio da Silva2014-02-141-1/+1
|\ | | | | Add hint to error message of task db:migrate:down
| * Add hint to error message of task db:migrate:downPhilippe Creux2014-02-131-1/+1
| |
* | Add config to disable schema dump after migrationEmil Soman2014-02-061-1/+1
|/ | | | | | | | | * Add a config on Active Record named `dump_schema_after_migration` * Schema dump doesn't happen if the config is set to false * Set default value of the config to true * Set config in generated production environment file to false * Update configuration guide * Update CHANGELOG
* Ensure Active Record connection consistencyschneems2014-01-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently Active Record can be configured via the environment variable `DATABASE_URL` or by manually injecting a hash of values which is what Rails does, reading in `database.yml` and setting Active Record appropriately. Active Record expects to be able to use `DATABASE_URL` without the use of Rails, and we cannot rip out this functionality without deprecating. This presents a problem though when both config is set, and a `DATABASE_URL` is present. Currently the `DATABASE_URL` should "win" and none of the values in `database.yml` are used. This is somewhat unexpected to me if I were to set values such as `pool` in the `production:` group of `database.yml` they are ignored. There are many ways that active record initiates a connection today: - Stand Alone (without rails) - `rake db:<tasks>` - ActiveRecord.establish_connection - With Rails - `rake db:<tasks>` - `rails <server> | <console>` - `rails dbconsole` We should make all of these behave exactly the same way. The best way to do this is to put all of this logic in one place so it is guaranteed to be used. Here is my prosed matrix of how this behavior should work: ``` No database.yml No DATABASE_URL => Error ``` ``` database.yml present No DATABASE_URL => Use database.yml configuration ``` ``` No database.yml DATABASE_URL present => use DATABASE_URL configuration ``` ``` database.yml present DATABASE_URL present => Merged into `url` sub key. If both specify `url` sub key, the `database.yml` `url` sub key "wins". If other paramaters `adapter` or `database` are specified in YAML, they are discarded as the `url` sub key "wins". ``` ### Implementation Current implementation uses `ActiveRecord::Base.configurations` to resolve and merge all connection information before returning. This is achieved through a utility class: `ActiveRecord::ConnectionHandling::MergeAndResolveDefaultUrlConfig`. To understand the exact behavior of this class, it is best to review the behavior in activerecord/test/cases/connection_adapters/connection_handler_test.rb though it should match the above proposal.
* create/drop test and development databases only if RAILS_ENV is nilDamien Mathieu2014-01-081-2/+2
| | | | Closes #13625
* Add deprecation I accidentally missedJon Leighton2014-01-041-1/+1
|
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-03 14:11:48 +0000