| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| | |
samphilipd/sam/manual_locking_on_schema_migrations
Make migrations concurrent safe (using advisory locks)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Addresses issue #22092
- Works on Postgres and MySQL
- Uses advisory locks because of two important properties:
1. The can be obtained outside of the context of a transaction
2. They are automatically released when the session ends, so if a
migration process crashed for whatever reason the lock is not left
open perpetually
- Adds get_advisory_lock and release_advisory_lock methods to database
adapters
- Attempting to run a migration while another one is in process will
raise a ConcurrentMigrationError instead of attempting to run in
parallel with undefined behavior. This could be rescued and
the migration could exit cleanly instead. Perhaps as a configuration
option?
Technical Notes
==============
The Migrator uses generate_migrator_advisory_lock_key to build the key
for the lock. In order to be compatible across multiple adapters there
are some constraints on this key.
- Postgres limits us to 64 bit signed integers
- MySQL advisory locks are server-wide so we have to scope to the
database
- To fulfil these requirements we use a Migrator salt (a randomly
chosen signed integer with max length of 31 bits) that identifies
the Rails migration process as the owner of the lock. We multiply
this salt with a CRC32 unsigned integer hash of the database name to
get a signed 64 bit integer that can also be converted to a string
to act as a lock key in MySQL databases.
- It is important for subsequent versions of the Migrator to use the
same salt, otherwise different versions of the Migrator will not see
each other's locks.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The first one is quite straightforward. We want to give the proper error
message in the case where a top level constant exists, but we're looking
for a nested one. We just need to port over the change to use
`subclass.name` into these changes.
The second set of failures, which are only present in the mysql adapter
tests, are stranger to me. The failure occurs because we were
previously comparing `subclass.name == self.name` instead of `subclass
== self`. However, I don't think that we need to support creating
anonymous classes which share a table with a class that uses STI,
overrides `name` to return the same name as athe class that we have no
other relationship with, when not assigned to a constant so it could
never be used anyway...
The commits around why that exist give no context, and I think they're
just poorly written tests (WTF does `test_schema` mean anyway, and why
does calling `.first` on some anonymous class test it?). We'll just
disable STI on that class.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This solves the following issue:
```
$ bin/test
Using sqlite3
/Users/senny/Projects/rails/activerecord/test/cases/adapters/mysql2/sp_test.rb:16:in `<class:Mysql2StoredProcedureTest>': undefined method `version' for #<ActiveRecord::ConnectionAdapters::SQLite3Adapter:0x007f8bab4b5b70> (NoMethodError)
from /Users/senny/Projects/rails/activerecord/test/cases/adapters/mysql2/sp_test.rb:5:in `<top (required)>'
from /Users/senny/Projects/rails/activesupport/lib/active_support/dependencies.rb:302:in `require'
from /Users/senny/Projects/rails/activesupport/lib/active_support/dependencies.rb:302:in `block in require'
from /Users/senny/Projects/rails/activesupport/lib/active_support/dependencies.rb:268:in `load_dependency'
from /Users/senny/Projects/rails/activesupport/lib/active_support/dependencies.rb:302:in `require'
from /Users/senny/Projects/rails/railties/lib/rails/test_unit/test_requirer.rb:11:in `block in require_files'
from /Users/senny/Projects/rails/railties/lib/rails/test_unit/test_requirer.rb:10:in `each'
from /Users/senny/Projects/rails/railties/lib/rails/test_unit/test_requirer.rb:10:in `require_files'
from /Users/senny/Projects/rails/railties/lib/rails/test_unit/minitest_plugin.rb:69:in `plugin_rails_init'
from /Users/senny/.rbenv/versions/2.2.3/lib/ruby/gems/2.2.0/gems/minitest-5.3.3/lib/minitest.rb:73:in `block in init_plugins'
from /Users/senny/.rbenv/versions/2.2.3/lib/ruby/gems/2.2.0/gems/minitest-5.3.3/lib/minitest.rb:71:in `each'
from /Users/senny/.rbenv/versions/2.2.3/lib/ruby/gems/2.2.0/gems/minitest-5.3.3/lib/minitest.rb:71:in `init_plugins'
from /Users/senny/.rbenv/versions/2.2.3/lib/ruby/gems/2.2.0/gems/minitest-5.3.3/lib/minitest.rb:122:in `run'
from bin/test:19:in `<main>'
```
|
|
|
|
|
|
| |
This issue was resolved by #21687 already. But re-add args by #18856.
`#tables` extra args was only using by `#table_exists?`. This is for
internal API. This commit will remove these extra args again.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prior to this commit, Rails makes no differentiation between whether a
query uses bind parameters, and whether or not we cache that query as a
prepared statement. This leads to the cache populating extremely fast in
some cases, with the statements never being reused.
In particular, the two problematic cases are `where(foo: [1, 2, 3])` and
`where("foo = ?", 1)`. In both cases we'll end up quoting the values
rather than using a bind param, causing a cache entry for every value
ever used in that query.
It was noted that we can probably eventually change `where("foo = ?",
1)` to use a bind param, which would resolve that case. Additionally, on
PG we can change our generated query to be `WHERE foo = ANY($1)`, and
pass an array for the bind param. I hope to accomplish both in the
future.
For SQLite and MySQL, we still end up preparing the statements anyway,
we just don't cache it. The statement will be cleaned up after it is
executed. On postgres, we skip the prepare step entirely, as an API is
provided to execute with bind params without preparing the statement.
I'm not 100% happy on the way this ended up being structured. I was
hoping to use a decorator on the visitor, rather than mixing a module
into the object, but the way Arel has it's visitor pattern set up makes
it very difficult to extend without inheritance. I'd like to remove the
duplication from the various places that are extending it, but that'll
require a larger restructuring of that initialization logic. I'm going
to take another look at the structure of it soon.
This changes the signature of one of the adapter's internals, and will
require downstream changes from third party adapters. I'm not too
worried about this, as worst case they can simply add the parameter and
always ignore it, and just keep their previous behavior.
Fixes #21992.
|
|\
| |
| | |
Add stored procedure test in mysql2
|
| | |
|
|/
|
|
|
|
| |
Currently `tinyblob` is dumped to `t.binary "tiny_blob", limit: 255`.
But `t.binary ... limit: 255` is generating SQL to `varchar(255)`.
It is incorrect. This commit fixes this problem.
|
|\
| |
| | |
Allow mysql and mysql2 tests run by database user with password
|
| | |
|
| |
| |
| |
| |
| |
| | |
`pk_and_sequence_for` is implemented for PG and MySQL adapters (not
implemented for Sqlite3 adapter). But MySQL adapters are not using
`pk_and_sequence_for` already.
|
|\ \
| | |
| | |
| | | |
Fix a bug with returning_disabled when using the postgresql adapter
|
| | |
| | |
| | |
| | | |
The returning_disabled configuration option is required to make postgresql partitioning triggers work. This commit fixes a bug where an invalid query would be made in cases where returning_disabled was true and objects were created with no attributes defined.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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)
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We should not run MysqlAdapter tests when running with `sqlite3_mem`.
This also moves the test-case outside the MysqlAdapter namespace. This
will prevent the following error when running everything:
```
1) Error:
TestAdapterWithInvalidConnection#test_inspect_on_Model_class_does_not_raise:
TypeError: superclass mismatch for class MysqlAdapter
```
|
|/ / |
|
|\ \
| | |
| | | |
Refactor `table_exists?` in AbstractMysqlAdapter
|
| | |
| | |
| | |
| | |
| | |
| | | |
`table_exists?` calls `tables` twice when passed `'dbname.tblname'` arg.
This change is that `table_exists?` execute only once query always and
extra args of `tables` is removed.
|
|/ / |
|
|\ \
| | |
| | |
| | | |
Add `unsigned` support for numeric data types in MySQL
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In the case of using `unsigned` as the type:
create_table :foos do |t|
t.unsigned_integer :unsigned_integer
t.unsigned_bigint :unsigned_bigint
t.unsigned_float :unsigned_float
t.unsigned_decimal :unsigned_decimal, precision: 10, scale: 2
end
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Example:
create_table :foos do |t|
t.integer :unsigned_integer, unsigned: true
t.bigint :unsigned_bigint, unsigned: true
t.float :unsigned_float, unsigned: true
t.decimal :unsigned_decimal, unsigned: true, precision: 10, scale: 2
end
|
|\ \ \
| | | |
| | | |
| | | | |
Move `explain` into `AbstractMysqlAdapter`
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Common methods in both mysql adapters are should be added to
`AbstractMysqlAdapter`, but some methods had been added to
`Mysql2Adapter`. (8744632f, 0306f82e, #14359)
Some methods already moved from `Mysql2Adapter` to
`AbstractMysqlAdapter`. (#17601, #17998)
Common methods in both mysql adapters are remaining only the `explain`
method in `Mysql2Adapter`.
|
|\ \ \ \
| | | | |
| | | | | |
Remove unnecessary display width
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The **(11)** does not affect the storage size of the data type, which for an
INT will always be 4 bytes. It affects the **display width**.
http://www.tocker.ca/2015/07/02/proposal-to-deprecate-mysql-integer-display-width-and-zerofill.html
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Some test cases are testing only mysql adapter. We should test mysql2
adapter also.
|
| |_|/ /
|/| | |
| | | |
| | | |
| | | | |
`@connection` in `StatementPool` is only used for PG adapter.
No need for abstract `StatementPool` class.
|
|/ / / |
|
|\ \ \
| | | |
| | | | |
Add tests for test/cases/adapters/mysql2/view_test.rb
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Basically view tests for MySQL are same with
`test/cases/adapters/postgresql/view_test.rb`.
So move `test/cases/adapters/postgresql/view_test.rb` to
`test/cases/view_test.rb` and make them only run if
`current_adapter` supports writable view.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Apparently I managed to forget how similar the "tests passing" and
"no status reported" merge indicators look.
Note that the previous `stubs` in test_add_index wasn't working:
the method was still called, and just happened to return false.
|
|/ / /
| | |
| | |
| | |
| | | |
See http://www.postgresql.org/docs/9.4/static/sql-dropindex.html
for more details.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Closes #21418.
Previously schema names were not quoted. This leads to issues when a
schema names contains a ".". Methods in `schema_statements.rb` should
quote user input.
|
| | | |
|
| | | |
|
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| | |
As of MySQL 5.7.8, MySQL supports a native JSON data type.
Example:
create_table :json_data_type do |t|
t.json :settings
end
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
As described in the "Follow Coding Conventions" section in our
contribution guide (http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html#follow-the-coding-conventions)
we favor `assert_not` over `refute`.
While we don't usually make stylistic changes on it's own I opted to do
it in this case. The reason being that test cases are usually copied as
a starting point for new tests. This results in a spread of `refute` in
files that have been using it already.
|
| | |
|
| |
| |
| |
| | |
this fixes a failing test case
|
| |
| |
| |
| | |
support it. Fixes #19711
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This introduces a deprecation cycle to change the behavior of the
default point type in the PostgreSQL adapter. The old behavior will
continue to be available for the immediate future as `:legacy_point`.
The current behavior of returning an `Array` causes several problems,
the most significant of which is that we cannot differentiate between an
array of points, and a point itself in the case of a column with the
`point[]` type.
The attributes API gives us a reasonable way to have a proper
deprecation cycle for this change, so let's take advantage of it. If we
like this change, we can also add proper support for the other geometric
types (line, lseg, box, path, polygon, and circle), all of which are
just aliases for string today.
Fixes #20441
|
| | |
|
| |
| |
| |
| | |
Related with #17370.
|
| | |
|
|\ \
| | |
| | |
| | | |
Correctly dump `:options` on `create_table` for MySQL
|
| | | |
|