| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Follow up to #23508.
|
|\
| |
| | |
`schema_type` returns symbol rather than string
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
A return value of `schema_type` is used by:
1. primary key type: using as `symbol.inspect`
2. normal column type: using as `symbol.to_s`
It is better to return symbol.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this addition, you can add a column into the table like:
```
create_table(:numeric_types) do |t|
t.numeric :foo, precision: 10, scale: 2, default: 2.0
end
```
The result of the migration above is same with:
```
create_table(:numeric_types) do |t|
t.decimal :foo, precision: 10, scale: 2, default: 2.0
end
```
|
|\
| |
| |
| |
| | |
kamipo/innodb_supports_fulltext_and_spatial_indexes
InnoDB supports FULLTEXT and Spatial Indexes [ci skip]
|
| |
| |
| |
| |
| | |
https://dev.mysql.com/doc/refman/5.7/en/innodb-fulltext-index.html
https://dev.mysql.com/doc/refman/5.7/en/creating-spatial-indexes.html
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a `before_commit` callback raises, the database is rolled back but
AR's record of the current transaction is not, leaving the connection in
a perpetually broken state that affects all future users of the
connection: subsequent requests, jobs, etc. They'll think a transaction
is active when none is, so they won't BEGIN on their own. This manifests
as missing `after_commit` callbacks and broken ROLLBACKs.
This happens because `before_commit` callbacks fire before the current
transaction is popped from the stack, but the exception-handling path
they hit assumes that the current transaction was already popped. So the
database ROLLBACK is issued, but the transaction stack is left intact.
Common cause: deadlocked `#touch`, which is now implemented with
`before_commit` callbacks.
What's next:
* We shouldn't allow active transaction state when checking in or out
from the connection pool. Verify that conns are clean.
* Closer review of txn manager sad paths. Are we missing other spots
where we'd end up with incorrect txn state? What's the worst that can
happen if txn state drifts? How can we guarantee it doesn't and
contain the fallout if it does?
Thanks for @tomafro for expert diagnosis!
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`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.
|
|\
| |
| |
| |
| | |
yui-knk/warning_when_composite_primary_key_is_detected
Warn if `AR.primary_key` is called for a table who has composite prim…
|
| |
| |
| |
| |
| |
| |
| |
| | |
If `AR.primary_key` is called for a table who has composite primary key,
the method returns `nil`. This behavior sometimes generates invalid SQL.
The first time developers notice to invalid SQL is when they execute
SQL. This commit enables developers to know they are doing something
dangerous as soon as possible.
|
|\ \
| | |
| | | |
Refactor `column_exists?` in `SchemaStatements`
|
| |/ |
|
|/
|
|
|
|
| |
`ActiveRecord::ConnectionAdapters::SchemaStatements#columns` is defined
here as an interface method here. So changes to raise `NotImplementedError`
same as `tables`, `views` ...etc.
|
|\
| |
| | |
Clarify DatabaseStatements#execute docs re: memory usage.
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
This line causes an error when executing the command: `rails db:drop db:create db:schema:load`
ActiveRecord::StatementInvalid: PG::SyntaxError: ERROR: syntax error at or near "{"
LINE 1: ...NSERT INTO "schema_migrations" (version) VALUES (#{v}), (#{v...
|
| |
| |
| |
| |
| |
| |
| | |
We found that inserting all 600 schema_migrations for our mid-sized app takes about a minute on a cloud based CI environment.
I assume that the original code did not use multi-row-insert because SQLite3 was not supporting the syntax back then,
but it's been supported since 3.7.11: http://www.sqlite.org/releaselog/3_7_11.html
|
|/
|
|
|
|
|
|
|
|
| |
- Using `references` or `belongs_to` in migrations will always add index
for the referenced column by default, without adding `index:true` option
to generated migration file.
- Users can opt out of this by passing `index: false`.
- Legacy migrations won't be affected by this change. They will continue
to run as they were before.
- Fixes #18146
|
|\
| |
| | |
Add `:expression` option support on the schema default
|
| |
| |
| |
| |
| |
| |
| |
| | |
Example:
create_table :posts do |t|
t.datetime :published_at, default: -> { 'NOW()' }
end
|
|/ |
|
|
|
|
| |
Closes #22584.
|
|\
| |
| | |
Prevent destructive action on production database
|
| |
| |
| |
| |
| |
| |
| | |
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`.
|
|\ \
| | |
| | | |
Fix `select_values` method signature for consistency
|
| | | |
|
|/ /
| |
| |
| | |
Simply `{update|delete}_sql` aliases to `{update|delete}`.
|
| |
| |
| |
| | |
`connection.insert_sql` is almost the same as `connection.insert`.
|
| |
| |
| |
| |
| |
| | |
Originally `connection#create` had aliased to `connection#insert` in PG
adapter. But it was broken by #7447. Re-alias `create` to `insert` for
fixing it.
|
|\ \
| | |
| | | |
Allow add_to_transaction with null transaction
|
| | |
| | |
| | |
| | | |
Fixes https://github.com/rails/rails/issues/22819
|
|\ \ \
| |/ /
|/| | |
Add `columns_for_distinct` for MySQL 5.7 with ONLY_FULL_GROUP_BY
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In MySQL 5.7.5 and up, ONLY_FULL_GROUP_BY affects handling of queries
that use DISTINCT and ORDER BY. It requires the ORDER BY columns in the
select list for distinct queries, and requires that the ORDER BY include
the distinct column.
See https://dev.mysql.com/doc/refman/5.7/en/group-by-handling.html
|
|\ \ \
| | | |
| | | | |
`join_to_delete` is same as `join_to_update`
|
| | | |
| | | |
| | | |
| | | | |
Reapply #22615.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
kamipo/join_to_delete_is_same_as_join_to_update"
This reverts commit 4d06ea9a829de8f6f5a345589828e182eacab6a3, reversing
changes made to e9d15072a94e2ae4dec5b7a121c84a5db38547b8.
Reason: This will break oracle-enhanced, see
https://github.com/rsim/oracle-enhanced/blob/3c42131db82b64ac41645db3affc6e4650289df6/lib/active_record/connection_adapters/oracle_enhanced_adapter.rb#L1254
|
| | |/
| |/| |
|
| | |
| | |
| | |
| | | |
Follow up to #22642.
|
| |/
|/| |
|
|\ \
| | |
| | |
| | |
| | |
| | | |
byroot/do-not-include-column-limit-if-it-is-default
Do not include column limit in schema.rb if it matches the default
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When working on engines that supports multiple databases, it's
very annoying to have a different schema.rb output based on which
database you use. MySQL being the primary offender.
This patch should reduce the disparities a bit.
|
| | | |
|
| |/
|/| |
|
| |
| |
| |
| |
| | |
Even though this means more things to change when we bump after a
release, it's more important that our examples are directly copyable.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If we use a real version, at best that'll be an onerous update required
for each release; at worst, it will encourage users to write new
migrations against an older version than they're using.
The other option would be to leave these bare, without any version
specifier. But as that's just a variant spelling of "4.2", it would seem
to raise the same concerns as above.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The previous message was misleading (especially for Ops guys) when
diagnosing problems related to the database connection.
The message was suggesting that the connection cannot be obtained which
normally assumes the need to look at the database.
But this isn't the case as the connection could not be retrieved from
the application's internal connection pool.
The new message should make it more explicit and remove the confusion.
|
|\ \
| | |
| | |
| | |
| | | |
kamipo/not_passing_native_database_types_to_table_definition
Not passing `native_database_types` to `TableDefinition`
|
| | |
| | |
| | |
| | |
| | |
| | | |
The `native_database_types` only used in `TableDefinition` for look up
the default `:limit` option. But this is duplicated process with
`type_to_sql`. Passing `native_database_types` is not needed.
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Reported on #21509, how views is treated by `#tables` are differ
by each adapters. To fix this different behavior, after Rails 5.0
is released, deprecate `#tables`.
And `#table_exists?` would check both tables and views.
To make their behavior consistent with `#tables`, after Rails 5.0
is released, deprecate `#table_exists?`.
|