| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Fixes: #16313
|
|
|
|
|
|
|
|
|
| |
When set to an integer, a warning will be logged whenever a result set
larger than the specified size is returned by a query. Fixes #16463
The warning is outputed a module which is prepended in an initializer,
so there will be no performance impact if
`config.active_record.warn_on_records_fetched_greater_than` is not set.
|
|
|
|
| |
Avoid loading user's psqlrc when loading test structure
|
|\
| |
| |
| |
| |
| | |
pinglamb/fix-referencing-wrong-alias-when-joining-tables-of-has-many-through-association
Fix referencing wrong aliases while joining tables of has many through association
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
association
While joining table of has_many :through association, ActiveRecord will
use the actual table name instead of through-join alias. It results with
a wrong SQL and exception is raised. This only happens when calculation
methods like #count is called.
This issue is affecting Rails 4.1.x and 4.2.x as well.
|
|\ \
| | |
| | | |
PostgreSQL, Add test case for "Infinity" string assignment to float columns
|
| |/
| |
| |
| | |
This is implemented in Type::Float, but not tested, so far.
|
| | |
|
|/
|
|
|
|
|
| |
The subtype will (quite reasonably) ignore the possibility that it has
`changed_in_place?` by becoming nil.
Fixes #19467
|
|
|
|
|
|
|
|
|
|
| |
As described here https://github.com/rails/rails/issues/19420. When
using the Postgres BigInt[] field type the big int value was not being
translated into schema.rb. This caused the field to become just a
regular integer field when building off of schema.rb. This fix will
address this by delegating the limit from the subtype to the Array type.
https://github.com/rails/rails/issues/19420
|
|
|
|
|
|
|
| |
Preserving RACK_ENV behavior.
This reverts commit 7bdc7635b885e473f6a577264fd8efad1c02174f, reversing
changes made to 45786be516e13d55a1fca9a4abaddd5781209103.
|
|
|
|
| |
Fixes #19389.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a better test for 51660f0. It is testing that the SQL is the
same before and after the previously leaky scope is called. Before if
`hotel.drink_designers` was called first then `hotel.recipes` would
incorrectly get the scope applied. We want to be sure that the
polymorphic hm:t association is not leaking into or affecting the
SQL for the hm:t association on `Hotel`.
The reason I couldn't do this before was because there was an issue with
the SQL getting cached and wanted to resolve that later and then fix the
test to be better. Because of the caching, this test requires that
`Hotel.reflect_on_association(:recipes).clear_association_scope_cache`
be called after the first call to `hotel.recipes` to clear the
assocation scope chain and not interfere with the rest of the test.
|
|\
| |
| |
| |
| |
| |
| | |
Reuse the CollectionAssociation#reader proxy cache if the foreign key is present from the start.
Conflicts:
activerecord/CHANGELOG.md
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
present from the start.
When a new record has the necessary information prior to save, we can
avoid busting the cache.
We could simply clear the @proxy on #reset or #reset_scope, but that
would clear the cache more often than necessary.
|
| |
| |
| |
| |
| |
| |
| | |
Fixes db:structure:dump when using schema_search_path and PostgreSQL
extensions.
Closes #17157.
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I’m renaming all instances of `use_transcational_fixtures` to
`use_transactional_tests` and “transactional fixtures” to
“transactional tests”.
I’m deprecating `use_transactional_fixtures=`. So anyone who is
explicitly setting this will get a warning telling them to use
`use_transactional_tests=` instead.
I’m maintaining backwards compatibility—both forms will work.
`use_transactional_tests` will check to see if
`use_transactional_fixtures` is set and use that, otherwise it will use
itself. But because `use_transactional_tests` is a class attribute
(created with `class_attribute`) this requires a little bit of hoop
jumping. The writer method that `class_attribute` generates defines a
new reader method that return the value being set. Which means we can’t
set the default of `true` using `use_transactional_tests=` as was done
previously because that won’t take into account anyone using
`use_transactional_fixtures`. Instead I defined the reader method
manually and it checks `use_transactional_fixtures`. If it was set then
it should be used, otherwise it should return the default, which is
`true`. If someone uses `use_transactional_tests=` then it will
overwrite the backwards-compatible method with whatever they set.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If there was a polymorphic hm:t association with a scope AND second
non-scoped hm:t association on a model the polymorphic scope would leak
through into the call for the non-polymorhic hm:t association.
This would only break if `hotel.drink_designers` was called before
`hotel.recipes`. If `hotel.recipes` was called first there would be
no problem with the SQL.
Before (employable_type should not be here):
```
SELECT COUNT(*) FROM "drink_designers" INNER JOIN "chefs" ON
"drink_designers"."id" = "chefs"."employable_id" INNER JOIN
"departments" ON "chefs"."department_id" = "departments"."id" WHERE
"departments"."hotel_id" = ? AND "chefs"."employable_type" = ?
[["hotel_id", 1], ["employable_type", "DrinkDesigner"]]
```
After:
```
SELECT COUNT(*) FROM "recipes" INNER JOIN "chefs" ON "recipes"."chef_id"
= "chefs"."id" INNER JOIN "departments" ON "chefs"."department_id" =
"departments"."id" WHERE "departments"."hotel_id" = ? [["hotel_id", 1]]
```
From the SQL you can see that `employable_type` was leaking through when
calling recipes. The solution is to dup the chain of the polymorphic
association so it doesn't get cached. Additionally, this follows
`scope_chain` which dup's the `source_reflection`'s `scope_chain`.
This required another model/table/relationship because the leak only
happens on a hm:t polymorphic that's called before another hm:t on the
same model.
I am specifically testing the SQL here instead of the number of records
becasue the test could pass if there was 1 drink designer recipe for the
drink designer chef even though the `employable_type` was leaking through.
This needs to specifically check that `employable_type` is not in the SQL
statement.
|
| |
|
|
|
|
| |
This change was prompted by 598b841.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
As of Ruby 2.2, Psych can handle any object which is marshallable. This
was not true on previous versions of Ruby, so our delegator types had to
provide their own implementation of `init_with` and `encode_with`.
Unfortunately, this doesn't match up with what Psych will do today.
Since by the time we hit this layer, the objects will have already been
created, I think it makes the most sense to just grab the current type
from the class.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I should have done this in the first place. We are now serializing an
explicit version so we can make more careful changes in the future. This
will load Active Record objects which were serialized in Rails 4.1.
There will be bugs, as YAML serialization was at least partially broken
back then. There will also be edge cases that we might not be able to
handle, especially if the type of a column has changed.
In addition, we're passing this as `from_database`, since that is
required for serialized columns at minimum. All other types were
serializing the cast value. At a glance, there should be no types for
which this is a problem.
Finally, dirty checking information will be lost on records serialized
in 4.1, so no columns will be marked as changed.
|
|
|
|
|
|
|
|
|
|
| |
The table is being modified in tests, without reloading the column
information on the appropriate class. This is leading to incorrect
column information in many cases.
The failures fixed by this commit can be replicated with:
ARCONN=postgresql ruby -Itest test/cases/adapters/postgresql/hstore_test.rb --seed 21574
|
|
|
|
|
|
|
|
|
|
|
| |
The default value of `"pg_arrays"."tags"` is being changed to `[]` in
one test, but the column information on the model isn't reset after it's
changed back. As such, we think the default value is `[]` when in the
database it's actually `nil`. That means any test which was assigning
`[]` to a new record would have that key skipped with partial writes, as
it hasn't changed from the default. However since the *actual* default
value is `nil`, we get back values that the test doesn't expect, and it
fails.
|
|\
| |
| | |
Fix rollback of frozen records
|
| | |
|
| | |
|
|\ \
| | |
| | | |
Run all our tests in random order
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This reverts commit 2f52f969885b2834198de0045748436a4651a94e.
Conflicts:
actionmailer/test/abstract_unit.rb
actionview/test/abstract_unit.rb
activemodel/test/cases/helper.rb
activerecord/test/cases/helper.rb
activesupport/test/abstract_unit.rb
railties/test/abstract_unit.rb
|
| | |
| | |
| | |
| | |
| | | |
Using a subclass to check the sequence name does not work in that case.
The sequence name will be calucalted based on the base class.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This reverts commit ff18049ca6f27deb7e7f955478e1464f8d756332.
This broke the AR build for every adapter:
1) Error:
AssociationCallbacksTest#test_dont_add_if_before_callback_raises_exception:
Exception: You can't add a post
2) Failure:
QueryCacheTest#test_query_cache_doesnt_leak_cached_results_of_rolled_back_queries [/Users/senny/Projects/rails/activerecord/test/cases/query_cache_test.rb:235]:
Expected: 1
Actual: 0
I'm reverting to get the build green again.
|
| | | |
|
| | |
| | |
| | |
| | | |
prompted by #19221.
|
| | | |
|
|/ / |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
`PostgresqlLargeKeysTest` is duplicated `PrimaryKeyBigSerialTest` in
`primary_keys_test.rb`.
|
|/ |
|
|\
| |
| | |
Fixes reference for schema_format to AR::Base from AS::Base
|
| | |
|
| | |
|
|\ \
| |/
|/| |
Added testcase for #18742
|
| | |
|
| |
| |
| |
| |
| | |
We've replaced most querues using DROP TABLE in our tests already.
This patch replaces the last couple calls.
|
|\ \
| | |
| | | |
Preserve Array#take(n) behaviour of HasManyAssociation
|
| | | |
|