| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
| | |
|
| |\
| |
| |
| |
| |
| | |
Introduce new ActiveRecord transaction error classes
Closes #26018
|
| | | |
|
| | |
| |
| |
| | |
`binds` is an array of a query attribute since Active Record 5.0.
|
| |/
|
|
| |
preventing infinite looping in some cases.
|
| |
|
|
| |
or deadlocks
|
| |
|
|
| |
as value
|
| |
|
|
| |
Fix failing tests
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Example:
create_table :users do |t|
t.string :name
t.index 'lower(name) varchar_pattern_ops'
end
Fixes #19090.
Fixes #21765.
Fixes #21819.
Fixes #24359.
Signed-off-by: Jeremy Daer <jeremydaer@gmail.com>
|
| |
|
|
|
|
| |
There is no need to fetch all table indexes in remove_index if name is specified. If name is wrong, then StatementInvalid will be raised.
Signed-off-by: Jeremy Daer <jeremydaer@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we were assuming that the only valid types for encoding were
arrays and hashes. However, any JSON primitive is an accepted value by
both PG and MySQL.
This does involve a minor breaking change in the handling of `default`
in the schema dumper. This is easily worked around, as passing a
hash/array literal would have worked fine in previous versions of Rails.
However, because of this, I will not be backporting this to 4.2 or
earlier.
Fixes #24234
|
| |
|
|
| |
I'm unsure how this passed CI in the pull request.
|
| |\
| |
| | |
Passing `table_name` to `Column#initialize` to avoid `instance_variable_set`
|
| | |
| |
| |
| |
| |
| |
| |
| | |
working
Currently the results of `column.serial?` is not correct. For
`column.serial?` correctly working, initialize `column.table_name`
immediately.
|
| |\ \
| | |
| | | |
Fix bigserial appears with limit 8 for schema dumper
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Before:
```ruby
create_table "postgresql_big_serials", force: :cascade do |t|
t.bigserial "seq", limit: 8, null: false
end
```
After:
```ruby
create_table "postgresql_big_serials", force: :cascade do |t|
t.bigserial "seq", null: false
end
```
|
| |/ |
|
| |
|
|
|
| |
Originally, `{insert|update|delete}_sql` is protected methods.
We can use the `{insert|update|delete}` public methods instead.
|
| | |
|
| |
|
|
|
|
| |
Some tests does not work for unprepared statements.
Add `if ActiveRecord::Base.connection.prepared_statements` and fix a
regex for fix tests failure with `prepared_statements: false`.
|
| |
|
|
| |
is falsy
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| | |
Add `:expression` option support on the schema default
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Example:
create_table :posts do |t|
t.datetime :published_at, default: -> { 'NOW()' }
end
|
| | | |
|
| |/
|
|
| |
Arel handles substitution for bind parameters by now.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is an alternate implementation to #22875, that generalizes a lot of
the logic that type decorators are going to need, in order to have them
work with arrays, ranges, etc. The types have the ability to map over a
value, with the default implementation being to just yield that given
value. Array and Range give more appropriate definitions.
This does not automatically make ranges time zone aware, as they need to
be added to the `time_zone_aware` types config, but we could certainly
make that change if we feel it is appropriate. I do think this would be
a breaking change however, and should at least have a deprecation cycle.
Closes #22875.
/cc @matthewd
|
| |
|
|
|
|
|
| |
uuid-ossp extension is alreadly enabled on test schema.
And `disable_extension!('uuid-ossp', connection)` can be a cause of test failure.
`ActiveRecord::StatementInvalid: PG::UndefinedFunction: ERROR: function uuid_generate_v1() does not exist`
will happen depending on the execution order.
|
| | |
|
| |\
| |
| |
| | |
Support passing the schema name prefix to `conenction.indexes`
|
| | |
| |
| |
| |
| |
| |
| | |
Support passing the schema name as a prefix to table name in
`ConnectionAdapters::SchemaStatements#indexes`. Previously the prefix would
be considered a full part of the index name, and only the schema in the
current search path would be considered.
|
| |\ \
| | |
| | |
| | | |
Ignore index name in `index_exists?` when not passed a name to check for
|
| | |/ |
|
| |/
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
Apart from specific versioning support, our tests should focus on the
behaviour of whatever version they're accompanying, regardless of when
they were written.
Application code should *not* do this.
|
| | |
|
| |
|
|
|
|
|
|
| |
This removes the following warning which has been out in the case of a PostgreSQL 9.3 below.
```
activerecord/test/cases/adapters/postgresql/geometric_test.rb:265: warning: instance variable @connection not initialized
```
|
| | |
|
| |
|
|
| |
`adapters/postgresql/geometric_test.rb`
|
| |
|
|
|
|
|
|
|
| |
- 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?`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
