| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | |
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | | |
|
|\ \ \
| |/ /
|/| | |
Move `UnknownAttributeError` to a more sane namespace
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The name `ActiveModel::AttributeAssignment::UnknownAttributeError` is
too implementation specific so let's move the constant directly under
the ActiveModel namespace.
Also since this constant used to be under the ActiveRecord namespace, to
make the upgrade path easier, let's avoid raising the former constant
when we deal with this error on the Active Record side.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Various behaviors needed by associations (such as creating the through
record) are lost when `where` is called, since we stop having a
`CollectionProxy` and start having an `AssociationRelation` which does
not contain this behavior. I *think* we should be able to rm
`AssociationRelation`, but we have tests saying the changes required to
do that would be bad (Without saying why. Of course. >_>)
Fixes #19073.
|
|\ \ \
| | | |
| | | | |
Add `SchemaMigration.create_table` support any unicode charsets for MySQL.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
MySQL unicode support is not only `utf8mb4`.
Then, The index length problem is not only `utf8mb4`.
http://dev.mysql.com/doc/refman/5.6/en/charset-unicode.html
SELECT * FROM information_schema.character_sets WHERE maxlen > 3;
+--------------------+----------------------+------------------+--------+
| CHARACTER_SET_NAME | DEFAULT_COLLATE_NAME | DESCRIPTION | MAXLEN |
+--------------------+----------------------+------------------+--------+
| utf8mb4 | utf8mb4_general_ci | UTF-8 Unicode | 4 |
| utf16 | utf16_general_ci | UTF-16 Unicode | 4 |
| utf16le | utf16le_general_ci | UTF-16LE Unicode | 4 |
| utf32 | utf32_general_ci | UTF-32 Unicode | 4 |
+--------------------+----------------------+------------------+--------+
|
|\ \ \ \
| |/ / /
|/| | |
| | | |
| | | | |
rebyn/fix/17161-remove-objs-from-has_many-updates-fields
Add specs for adding-to/clear has_many collections’s behavior on `updated_at`
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
There are behaviors mentioned in #17161 that:
1. are not documented properly, and
2. don't have specs
This commit addresses the spec absence. For has_many collections,
1. addition (<<) should update the associated object's updated_at (if any)
2. .clear, depending on options[:dependent], calls delete_all, destroy_all, or nullifies the associated object(s)' foreign key.
|
|\ \ \ \
| | | | |
| | | | | |
Spike on new transaction callbacks
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | | |
[fixes #18903]
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Add after_commit_without_transaction_enrollment and
after_rollback_without_transaction_enrollment private callbacks so we
can create after_commit and after_rollback callbacks without having the
records automatic enrolled in the transaction.
[fixes #18904]
|
|\ \ \ \ \
| |_|_|/ /
|/| | | | |
Rely on through table name in has_many fixtures
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Rather than using the association's join_table method, which
constructs a table name from conventions, this should rely on the
through reflection's table_name to be resilient to tables that were
not automatically named.
|
| | | | |
| | | | |
| | | | |
| | | | | |
Fix appending table_name to select and group when used with subquery (fr...
|
| | | | |
| | | | |
| | | | |
| | | | | |
boolean tinyint(1) fields
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
[Toby Ovod-Everett & Andrey Nering & Yves Senn]
Closes #17726.
Closes #10939.
This patch makes three distinct modifications:
1. no longer fall back to disabling user triggers if system triggers can't be disabled
2. warn the user when referential integrity can't be disabled
3. restore aborted transactions when referential integrity can't be disabled
The motivation behind these changes is to make the behavior of Rails
transparent and less error-prone. To require superuser privileges is not optimal
but it's what Rails currently needs. Users who absolutely rely on disabling user triggers
can patch `disable_referential_integrity`.
We should investigate `SET CONSTRAINTS` as a possible solution which does not require
superuser privileges.
/cc @matthewd
|
| | | | |
| | | | |
| | | | |
| | | | | |
`postgresql_xml_data_type` table is used from nowhere.
|