| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| | |
Remove legacy mysql adapter
|
| | |
|
|/
|
|
|
| |
Since the attributes API is new in Rails 5, we don't actually need to keep
the behavior of `attribute :point`, as it's not a breaking change.
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|\
| |
| | |
Allow users to pass flags from database.yml
|
| |
| |
| |
| |
| |
| | |
Fix white-space
Add test case demonstrating flags are received by the adapter
|
| |
| |
| |
| |
| | |
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.
|
|\ \
| |/
|/| |
Use adapter supports_datetime_with_precision
|
| | |
|
|\ \
| |/
|/| |
Explain the connection pool error message better [ci skip]
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|/
|
|
| |
`pool` in args is unused anymore. And `config` is used in all adapters.
|
|
|
|
| |
Not needed for `Mysql2Adapter` and `AbstractMysqlAdapter`.
|
| |
|
| |
|
|\
| |
| |
| |
| | |
kamipo/schema_dumping_support_for_postgresql_geometric_types
Add schema dumping support for PostgreSQL geometric data types
|
| | |
|
|\ \
| | |
| | |
| | |
| | | |
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.
|
| |/
|/|
| |
| | |
Not needed for `Mysql2Adapter` and `AbstractMysqlAdapter`.
|
| |
| |
| |
| |
| |
| |
| | |
This reverts commit 8246b593bff71f2cebf274c133bb8917f1e094c8.
There was concern about this modifying the behavior of past migrations.
We're going to add an way to modify the migration generator instead.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It's often the case that you want to have an option that you cannot
specify at the database level, but want applied to *all* tables that you
create. For example, you might want to specify `ROW_FORMAT=DYNAMIC` to
not have to limit text columns to length 171 for indexing when using
utf8mb4. This allows an easy way to specify this in your database
configuration.
While this change affects both MySQL and MySQL2, the test only covers
MySQL2, as the legacy mysql adapter appears to always return ASCII
strings, and is tangential to what we're actually doing.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- key was a poor choice of name. A key implies something that will
unlock a lock. The concept is actually more like a 'lock identifier'
- mysql documentation calls this a 'lock name'
- postgres documentation calls it a 'lock_id'
- Updated variable names to reflect the preferred terminology for the database in
question
|
| | |
|
|/
|
|
|
|
|
|
|
|
| |
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?`.
|
| |
|
| |
|
|
|
|
|
|
| |
Columns are no longer stored in an attribute since b8a533d.
[ci skip]
|
| |
|
|
|
|
| |
Such as #10404, #18206.
|
|\
| |
| |
| |
| | |
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.
|
|\ \
| | |
| | | |
PostgreSQL, Replace static connection param list by libpq's dynamic list
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This makes the connection adapter future-proof regarding to new parameters.
To maintain backward compatibility, :requiressl is added by hand. It is
deprecated by PostgreSQL since 2003, but still accepted by libpq.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In Postgres 8.1 the standard_conforming_strings setting was read-only,
meaning you got an error if you tried to update it. By filtering on
`context = 'user'` we only try to update the setting if it's
user-writable[1].
[1]: http://www.postgresql.org/docs/9.4/static/view-pg-settings.html
|
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The standard_conforming_strings setting doesn't exist on all versions of
Postgres, but if it does exist, Rails turns it on. Previously this was done by
effectively disabling errors on the Postgres connection, issuing a SET to turn
the setting on, then re-enabling errors on the connection. However, if you're
running pgbouncer in transaction-pooling mode, you can't guarantee that
successive calls to `#execute` will be sent to the same pgbouncer-postgres
connection, so you can end up disabling errors on a different postgres
connection, and never re-enabling them. Future queries on that connection that
result in errors (e.g. violating unique constraints) will leave the connection
in a bad state where successive queries will fail.
This commit sets standard_conforming_strings by issuing an UPDATE to
pg_settings, which will update the setting if it exists, and do nothing if it
doesn't (rather than erroring out like SET would), which means we can remove
the error-disabling code.
It's also worth noting that Postgres has allowed standard_conforming_strings to
be updated since 8.2 (which is the oldest version Rails supports), so
technically we probably don't even need to be defensive here.
|
| |
| |
| |
| |
| | |
`#exec_stmt` is private method and only called in `#exec_query`. it
means `binds` is provided always. No need `binds.empty?` checking.
|
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| | |
The getter is doing nothing more than returning the ivar, so it can be
extracted to an attr_reader.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
[ci skip]
It's been a source of confusion that the lower-level `add_column`
referenced the higher level `column` method for available options.
`column` supports additional functionality like `index: true` that is
not present on `add_column`.
This patch moves common option documentation to `add_column` and only
documents the additional options in `column`.
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The `SHOW TABLES LIKE` command accepts metacharacters `%` and `_` in
potentially unexpected ways. This can be avoided by querying `information_schema.tables`
directly.
Fixes #17897
|
| | |
| | |
| | |
| | |
| | | |
I've been writing too much Rust. My mind is still in the mode of things
being auto-namespaced based on the file...
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
| | | | |
|
| | | | |
|