| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|/
|
|
|
|
|
|
| |
PR #5210 added a Friendship model to illustrate a bug, but in doing so
created a confusing structure because both belongs_to declarations in
Friendship referred to the same side of the join. The new structure
maintains the integrity of the bug test while changing the follower
relationship to be more useful for other testing.
|
|
|
|
| |
Closes #9110
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This caused a bug with the new associations implementation, because now
association conditions are represented as Arel nodes internally right up
to when the whole thing gets turned to SQL.
In Rails 3.2, association conditions get turned to raw SQL early on,
which prevents Relation#merge from interfering.
The current implementation was buggy when a default_scope existed on the
target model, since we would basically end up doing:
default_scope.merge(association_scope)
If default_scope contained a where(foo: 'a') and association_scope
contained a where(foo: 'b').where(foo: 'c') then the merger would see
that the same column is representated on both sides of the merge and
collapse the wheres to all but the last: where(foo: 'c')
Now, the RHS of the merge is left alone.
Fixes #8990
|
|
|
|
| |
Rename `ActiveRecord::Fixtures` class to `ActiveRecord::FixtureSet`. Instances of this class normally hold a collection of fixtures (records) loaded either from a single YAML file, or from a file and a folder with the same name. This change make the class name singular and makes the class easier to distinguish from the modules like `ActiveRecord::TestFixtures`, which operates on multiple fixture sets, or `DelegatingFixtures`, `::Fixtures`, etc., and from the class `ActiveRecord::Fixture`, which corresponds to a single fixture.
|
|
|
|
|
| |
All tests with a custom inheritance_column use the `Vegtable` model.
The field ruby_type on the Company models is no longer needed
|
|
|
|
|
|
| |
previously the tests with and without a custom `inheritance_column`
used the same models. Since the model then has both fields this can lead
to false positives.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I had to create a new table because I needed an STI table,
which does not have both a "type" and a "custom_type"
the test fails with:
1) Error:
test_alt_becomes_works_with_sti(InheritanceTest):
NoMethodError: undefined method `type=' for #<Cabbage id: 1, name: "my cucumber", custom_type: "Cucumber">
/Users/username/Projects/rails/activemodel/lib/active_model/attribute_methods.rb:432:in `method_missing'
/Users/username/Projects/rails/activerecord/lib/active_record/attribute_methods.rb:100:in `method_missing'
/Users/username/Projects/rails/activerecord/lib/active_record/persistence.rb:165:in `becomes'
test/cases/inheritance_test.rb:134:in `test_becomes_works_with_sti'
test/cases/inheritance_test.rb:140:in `test_alt_becomes_works_with_sti'
|
|
|
|
|
|
| |
associations with the same foreign key.
This closes #5200.
|
|
|
|
|
|
|
|
|
| |
ActiveRecord::ConnectionAdapters::Column#microseconds did an unnecessary
conversion to from Rational to float when calculating the integer number
of microseconds. Some terminating decimal numbers in base10 are
repeating decimal numbers in base2 (the format of float), and
occasionally this causes a rounding error.
Patch & explanation originally from Logan Bowers.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Improve the derivation of HABTM join table name to take account of nesting.
It now takes the table names of the two models, sorts them lexically and
then joins them, stripping any common prefix from the second table name.
Some examples:
Top level models
(Category <=> Product)
Old: categories_products
New: categories_products
Top level models with a global table_name_prefix
(Category <=> Product)
Old: site_categories_products
New: site_categories_products
Nested models in a module without a table_name_prefix method
(Admin::Category <=> Admin::Product)
Old: categories_products
New: categories_products
Nested models in a module with a table_name_prefix method
(Admin::Category <=> Admin::Product)
Old: categories_products
New: admin_categories_products
Nested models in a parent model
(Catalog::Category <=> Catalog::Product)
Old: categories_products
New: catalog_categories_products
Nested models in different parent models
(Catalog::Category <=> Content::Page)
Old: categories_pages
New: catalog_categories_content_pages
Also as part of this commit the validity checks for HABTM assocations have
been moved to ActiveRecord::Reflection One side effect of this is to move when
the exceptions are raised from the point of declaration to when the association
is built. This is consistant with other association validity checks.
|
|
|
|
| |
serialized values to indifferent access.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
If a model belongs_to two associations with the same class, then reset_counters
will reset the wrong counter cache.
Finding the right reflection should use the foreign_key instead, which should
be unique.
|
|
|
|
|
|
| |
Test using fixtures with random names and model names, that is not following naming conventions but using set_fixture_class instead.
It is expected that the table name be defined in the model, but this is not explicitly tested here. This will need to be fixed.
|
|
|
|
| |
Make sure the table name of a model is reset in a test case after assigning ActiveRecord::Base.table_name_prefix and ActiveRecord::Base.table_name_suffix.
|
| |
|
|
|
|
|
|
|
|
|
| |
alexeymuranov/my_fix_for_prefix_suffix_fixtures_test"
This reverts commit f8e484d0f71114675ed04e987914d3f2815cb868, reversing
changes made to fa5adfb1e884bf21a7071ade634a820e37ac4db4.
Reason: broke the postgres tests.
|
|
|
| |
Make sure the table name of a model is reset in a test case after assigning ActiveRecord::Base.table_name_prefix and ActiveRecord::Base.table_name_suffix. This was somebody else's test case, so an independent opinion on the change can be helpful.
|
|
|
|
| |
link in fixture template [closes #2840]
|
|
|
|
| |
is 00:50 GMT+1. Without the quoting, the YAML parser would parse this as 00:50 UTC, into the local time of 01:50 GMT+1. Then, it would get written into the database in local time as 01:50. When it came back out the UTC date from the database and the UTC date of two weeks ago would be compared. The former would be 23:50, and the latter would be 00:50, so the two dates would differ, causing the assertion to fail. Quoting it prevents the YAML parser from getting involved.
|
|
|
|
|
|
| |
are in a timezone which is ahead of UTC but UTC is in the previous day still."
This reverts commit f92cefa95f44bcd550c402a7f5ba914f3bd783cc.
|
|
|
|
| |
timezone which is ahead of UTC but UTC is in the previous day still.
|
|
|
|
|
|
| |
test/cases/fixtures_test.rb when UTC and local time occur on different dates." I am pretty sure this was an incorrect fix, and it still failed in certain circumstances anyway. I am now unable to reproduce the original failure I was experiencing so will leave it for now and see if this pops up again.
This reverts commit e4479b2f1bc54edf155408d51dd3236955150ce1.
|
|
|
|
| |
test/cases/fixtures_test.rb when UTC and local time occur on different dates.
|
|
|
|
| |
as per the last version of the yml specifications : http://www.yaml.org/spec/1.2/spec.html#* alias//
|
| |
|
|
|
|
| |
Fixes #508.
|
| |
|
|
|
|
| |
delete method.
|
|
|
| |
[Fixes #439]
|
|\ |
|
| |
| |
| |
| | |
maintained), and rewrites the section about after and around filters in the controller guide
|
| |
| |
| |
| | |
the code which support this
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
activerecord/CHANGELOG
activerecord/lib/active_record/association_preload.rb
activerecord/lib/active_record/associations.rb
activerecord/lib/active_record/associations/class_methods/join_dependency.rb
activerecord/lib/active_record/associations/class_methods/join_dependency/join_association.rb
activerecord/lib/active_record/associations/has_many_association.rb
activerecord/lib/active_record/associations/has_many_through_association.rb
activerecord/lib/active_record/associations/has_one_association.rb
activerecord/lib/active_record/associations/has_one_through_association.rb
activerecord/lib/active_record/associations/through_association_scope.rb
activerecord/lib/active_record/reflection.rb
activerecord/test/cases/associations/has_many_through_associations_test.rb
activerecord/test/cases/associations/has_one_through_associations_test.rb
activerecord/test/cases/reflection_test.rb
activerecord/test/cases/relations_test.rb
activerecord/test/fixtures/memberships.yml
activerecord/test/models/categorization.rb
activerecord/test/models/category.rb
activerecord/test/models/member.rb
activerecord/test/models/reference.rb
activerecord/test/models/tagging.rb
|
| |\
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
activerecord/examples/performance.rb
activerecord/lib/active_record/association_preload.rb
activerecord/lib/active_record/associations.rb
activerecord/lib/active_record/associations/association_proxy.rb
activerecord/lib/active_record/autosave_association.rb
activerecord/lib/active_record/base.rb
activerecord/lib/active_record/nested_attributes.rb
activerecord/test/cases/relations_test.rb
|
| | |
| | |
| | |
| | | |
state:resolved]. Also fixed a bunch of other counter cache bugs in the process, as once I fixed this one others started appearing like nobody's business.
|
| | |
| | |
| | |
| | | |
the new record, so we don't get the database into a pickle
|
| | | |
|
| | |
| | |
| | |
| | | |
all use arel rather than SQL strings
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
belongs_to changes, then the has_many should be considered stale.
|
| |/ |
|
| |
| |
| |
| | |
was previously untested
|
| |
| |
| |
| | |
association
|
| |
| |
| |
| | |
association, where the source is a has_one or has_many
|
| |
| |
| |
| | |
through associations
|
| |
| |
| |
| | |
through association
|