| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
This message could be generated by `assert_predicate`, https://github.com/rails/rails/commit/1853a4f2c8b2bddfbde6aae80abb08310295201c#commitcomment-20546113
but I'd rather handwrite the message string if I could reduce magic from the code by doing so.
|
| |
|
|\
| |
| | |
Fix UUID primary key with default nil in legacy migration
|
| |
| |
| |
| |
| |
| | |
UUID primary key with no default value feature (#10404, #18206) was lost
in legacy migration caused by #25395 got merged. Restore the feature
again in legacy migration.
|
| | |
|
|/
|
|
| |
(I personally prefer writing one string in one line no matter how long it is, though)
|
|
|
|
|
|
|
|
|
|
| |
mtsmfm/disable-referential-integrity-without-superuser-privileges"
This reverts commit eeac6151a55cb7d5f799e1ae33aa64a839cbc3aa, reversing
changes made to 5c40239d3104543e70508360d27584a3e4dc5baf.
Reason: Broke the isolated tests.
https://travis-ci.org/rails/rails/builds/188721346
|
|\
| |
| |
| |
| | |
mtsmfm/disable-referential-integrity-without-superuser-privileges
Use `SET CONSTRAINTS` for `disable_referential_integrity` without superuser privileges
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
privileges
ref: 72c1557254
- We must use `authors` fixture with `author_addresses` because of its foreign key constraint.
- Tests require PostgreSQL >= 9.4.2 because it had a bug about `ALTER CONSTRAINTS` and fixed in 9.4.2.
|
| |
| |
| |
| |
| | |
Passing `name` to `tables` is already deprecated at #21601.
Passing `name` to `indexes` is also unused.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Per the regression commit below, the commit changes the behavior of
`#changed?`to consult the `#changed_in_place?` method on `Type::Value` classes.
Per this change, `PostgreSQL::OID::Hstore` needs to override this method
in order to compare the deserialized forms of the two arguments. In
Ruby, two hashes are considered equal even if their key order is
different. This commit helps to bring that behavior to `Hstore` values.
Fixes regression introduced by 8e633e505880755e7e366ccec2210bbe2b5436e7
Fixes #27502
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In f1a0fa9 we moved backend specific timestamp behavior out of the type
and into the adapter. This was in line with our general attempt to
reduce the number of adapter specific type subclasses. However, on PG,
the array type performs all serialization, including database encoding
in its serialize method.
This means that we have converted the value into a string before
reaching the database, so no adapter specific logic can be applied (and
this also means that timestamp arrays were using the default `.to_s`
method on the given object, which likely meant timestamps were being
ignored in certain cases as well)
Ultimately I want to do a more in depth refactoring which separates
database serializer objects from the active model type objects, to give
us a less awkward API for introducing the attributes API onto Active
Model.
However, in the short term, we follow the solution we've applied
elsewhere for this. Move behavior off of the type and into the adapter,
and use a data object to allow the type to communicate information up
the stack.
Fixes #27514.
|
| |
| |
| |
| |
| | |
Currently schema dumper does not dump array subtype `precision` and
`scale` options. This commit fixes the issue.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|\ \
| | |
| | | |
Fix `add_index` to normalize column names and options
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Currently does not work the following code.
```ruby
add_index(:people, ["last_name", "first_name"], order: { last_name: :desc, first_name: :asc })
```
Normalize column names and options to fix the issue.
|
| |/
|/| |
|
| |
| |
| |
| |
| | |
If it's enabled globally, it's on regardless of how individual threads
are set.
|
| | |
|
| |
| |
| |
| | |
Follow up to #25395.
|
|\ \
| | |
| | | |
Suppress migration message in the test
|
| | | |
|
|/ / |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Since 9.4, PostgreSQL recommends using `pgcrypto`'s `gen_random_uuid()`
to generate version 4 UUIDs instead of the functions in the `uuid-ossp`
extension.
These changes uses the appropriate UUID function depending on the
underlying PostgreSQL server's version, while maintaining
`uuid_generate_v4()` in older migrations.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Due to `assert_nothing_raised` this test was not really testing
anything.
- So updated it to assert that the query gives expected result.
- Also in general we can use `connection.unprepared_statement` for
testing queries w/o prepared statements but it can't be used in this
case. This test cases was added because when prepared_statements
config is set to false, then DetermineIfPreparableVisitor module
does not extended by Arel visitor resulting into an error. Ref: https://github.com/rails/rails/pull/22748.
- Because DetermineIfPreparableVisitor module does not get added to the
visitor chain only if prepared_statements is false while **setting up
connection**, not when `unprepared_statement` is used.
- I have also added an assertion for making sure that prepared_config
is set to false from the start, so that nobody accidentally removes
the connection setup using `arunit_without_prepared_statements` and
replaces it with stubs or unprepared_statement.
|
| |
| |
| |
| | |
Follow up to #27109.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- The query needs to be executed for hitting `select_all` so made sure
that query gets executed.
- Also instead of changing instance variable, just add new
configuration for prepared_statements: false and use it for this
test.
- This way we don't have to touch the internals of AR code and still
disable prepared statements config for this test.
|
|\ \
| | |
| | | |
use `force_encoding` instread of `encode!` to avoid `UndefinedConversionError`
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
`PG::TextEncoder::Array#encode` returns the encoded value with `ASCII-8BIT`.
But in some cases, trying to convert `ASCII-8BIT` to `UTF-8` cause an error.
```ruby
"{\xE3\x83\x95\xE3\x82\xA1\xE3\x82\xA4\xE3\x83\xAB}".encode!(Encoding::UTF_8)
# => Encoding::UndefinedConversionError: "\xE3" from ASCII-8BIT to UTF-8
```
Should use `force_encoding` to avoid this error.
Follow up to 7ba3a48df5bfdc5e98506bb829f937e03b55a5b3
Ref: https://github.com/rails/rails/pull/23619#issuecomment-189924036
|
| | | |
|
| | | |
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
As reported via #26904, there is a regression in how values for
Postgres' HStore column type are being processed, beginning in Rails 5.
Currently, the way that Active Record checks whether or not values need
to be serialized and put into the correct storage format is whether or
not it is a `Hash` object. Since `ActionController::Parameters` no
longer inherits from `Hash` in Rails 5, this conditional now returns
false. To remedy this, we are now checking to see whether the `value`
parameters being passed in responds to a certain method, and then
calling the `serialize` method, except this time with a real Hash
object. Keeping things DRY!
Fixes #26904.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
```
test/cases/adapters/postgresql/case_insensitive_test.rb:12: warning: ambiguous first argument; put parentheses or a space even after `/' operator
test/cases/adapters/postgresql/case_insensitive_test.rb:16: warning: ambiguous first argument; put parentheses or a space even after `/' operator
test/cases/adapters/postgresql/case_insensitive_test.rb:20: warning: ambiguous first argument; put parentheses or a space even after `/' operator
test/cases/adapters/postgresql/case_insensitive_test.rb:24: warning: ambiguous first argument; put parentheses or a space even after `/' operator
```
|
|\ \
| | |
| | |
| | | |
Fix case insensitive check for text column in pg
|
| | |
| | |
| | |
| | | |
There's no 'text to text' casting in the cast table so the feature detection fails.
|
| |/
|/| |
|
| |
| |
| |
| |
| | |
We've seen occasional Travis failures mentioning deadlocks. I think
they're escaping from this test.
|
| |
| |
| |
| |
| |
| | |
Test: JSON attribute value nil can be used in where(attr: nil)
Add changelog entry
|
| |
| |
| |
| |
| |
| | |
assert [1, 3].includes?(2) fails with unhelpful "Asserting failed" message
assert_includes [1, 3], 2 fails with "Expected [1, 3] to include 2" which makes it easier to debug and more obvious what went wrong
|
|/
|
|
|
|
| |
All indentation was normalized by rubocop auto-correct at 80e66cc4d90bf8c15d1a5f6e3152e90147f00772.
But heredocs was still kept absolute position. This commit aligns
heredocs indentation for consistency.
|
|
|
|
|
|
|
|
|
|
| |
There are some minor changes to the point type as I had forgotten that
this will affect the behavior of `t.point` in migrations and the schema
dumper so we need to handle those as well.
I'll say this again so I can convince myself to come up with a better
structure... TYPES SHOULD NOT CARE ABOUT SCHEMA DUMPING AND WE NEED TO
BETTER SEPARATE THESE.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I still think that this is something that should be handled in the pg
gem, but it's not going to end up happening there so we'll do it here
instead. Once we bump to pg 0.19 we can pass the encoding to the
`encode` method instead.
This issue occurs because C has no concept of encoding (or strings,
really). The bytes that we pass here when sending the value to the
database will always be interpreted as whatever encoding the connection
is currently configured to use. That means that roundtripping to the
database will lose no information
However, after assigning we round trip through our type system without
hitting the database. The only way that we can do the "correct" thin
here would be to actually give a reference to the connection to the
array type and have it check the current value of the connection's
encoding -- which I'm strongly opposed to. We could also pass in the
encoding when it's constructed, but since that can change independently
of the type I'm not a huge fan of that either.
This feels like a reasonable middle ground, where if we have an array of
strings we simply use the encoding of the string we're given.
Fixes #26326.
|
| |
|
|
|
|
| |
Fixes #26137.
|
|
|
|
|
| |
Because `sql_for_insert` is only called in `use_insert_returning?` is
true since #26002.
|