| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
`table_exists?` is already exist in `ModelSchema`.
https://github.com/rails/rails/blob/5cab344494c340ea82a35b46efa06b94f0b7730b/activerecord/lib/active_record/model_schema.rb#L339-L341
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
To define the attribute methods for a model, Active Record needs to know
the schema of the underlying table, which is usually achieved by making
a request to the database. This is undesirable behaviour while the app
is booting, for two reasons: it makes the boot process dependent on the
availability of the database, and it means every new process will make
one query for each table, which can cause issues for large applications.
However, if the application is using the schema cache dump feature, then
the schema cache already contains the necessary information, and we can
define the attribute methods without causing any extra database queries.
|
| |
|
|
| |
Closes #31998
|
| |
|
|
| |
This basically reverts 9d4f79d3d394edb74fa2192e5d9ad7b09ce50c6d
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
| |
|
|
| |
This reverts commit 407e0ab5e5cddf6a8b6b278b12f50772d13b4d86.
|
| |
|
|
|
|
| |
`#first_or_initialize` does not use attributes to data acquisition.
Therefore, there is a possibility of updating the different record than the one
specified in the key, I think this is not expected behavior.
|
| |
|
|
| |
for those who already migrated to Rails 5.0.0 beta
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
`initialize_schema_migrations_table` is called in every migrations.
https://github.com/rails/rails/blob/v5.0.0.beta1/activerecord/lib/active_record/migration.rb#L1080
https://github.com/rails/rails/blob/v5.0.0.beta1/activerecord/lib/active_record/schema.rb#L51
This means that extra `show variables` is called regardless of the
existence of `schema_migrations` table.
This change is to avoid extra `show variables` if `schema_migrations`
table exists.
|
| | |
|
| |
|
|
|
|
|
| |
Mysql has a weird bug where it cannot index a string column of utf8mb4 if it is over a certain character limit. To get compatibility with msql we can add a limit to the key column. 191 characters is a very long key, it seems reasonable to limit across all adapters since using a longer key wouldn't be supported in mysql.
Thanks to @kamipo for the original PR and the test refactoring.
Conversation: https://github.com/rails/rails/pull/23009#issuecomment-171416629
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use `t.index` in `create_table` instead of `add_index`
It is slightly more efficient.
Revert "Use `key` as primary key in schema."
This reverts commit 350ae6cdc1ea83e21c23abd10e7e99c9a0bbdbd2.
`:primary_key` option does nothing if `id: false`.
https://github.com/rails/rails/blob/v5.0.0.beta1/activerecord/lib/active_record/connection_adapters/abstract/schema_statements.rb#L251-L261
|
| | |
|
| |
|
|
| |
Discussion: https://github.com/rails/rails/pull/22967#discussion_r49137035
|
| | |
|
|
|
This PR introduces a key/value type store to Active Record that can be used for storing internal values. It is an alternative implementation to #21237 cc @sgrif @matthewd.
It is possible to run your tests against your production database by accident right now. While infrequently, but as an anecdotal data point, Heroku receives a non-trivial number of requests for a database restore due to this happening. In these cases the loss can be large.
To prevent against running tests against production we can store the "environment" version that was used when migrating the database in a new internal table. Before executing tests we can see if the database is a listed in `protected_environments` and abort. There is a manual escape valve to force this check from happening with environment variable `DISABLE_DATABASE_ENVIRONMENT_CHECK=1`.
|
