| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit b98d1e21635d8776de8893cc09bd86c71f6c78f0.
Closes #6609
Conflicts:
activerecord/lib/active_record/associations/has_and_belongs_to_many_association.rb
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A series of commits relating to preloading and scopes caused a regression.
Cloning the relation calls initialize_copy which resets a number of instance
variables to nil. Without this the scope thinks that it is already loaded
when it is called again.
Reverts the following commits:
13f1401a6cf0266a3b0a91b173f976db2d4e50f3
8491740ca5361ba9df20e1c8b906c709f5bfbc12
dffbb521a0d00c8673a3ad6e0e8ff526f32daf4e
Fixes #6575, #6576 & #6577
|
|
|
|
|
|
|
|
| |
The fix commited in e2a070c was returning the `new_target`, as
a try to return whatever user replaced association with. The
problem is, the resulting association target may be ordered
differently. In such case we want to return the target that
will be later used for that association.
|
| |
|
|
|
|
|
|
|
|
| |
Bug #6289
Conflicts:
activerecord/test/cases/associations/has_many_associations_test.rb
|
|
|
|
|
|
| |
Conflicts:
activerecord/test/cases/associations/has_many_associations_test.rb
|
| |
|
|
|
|
|
|
|
|
| |
(as described in #5667)
Conflicts:
activerecord/test/cases/associations/eager_test.rb
|
|
|
|
|
|
|
|
| |
Causes a subtle regression where record.reload includes the default
scope. Hard to reproduce in isolation. Seems like the relation is
getting infected by some previous usage.
This reverts commit dffbb521a0d00c8673a3ad6e0e8ff526f32daf4e.
|
|
|
|
|
|
| |
Conflicts:
activerecord/test/cases/associations/eager_test.rb
|
|
|
|
| |
to address ORA-00918 error
|
|
|
|
|
|
|
| |
Also skip persistente tests related to UPDATE + ORDER BY for postgresql
PostgreSQL does not support updates with order by, and these tests are
failing randomly depending on the fixture loading order now.
|
| |
|
|
|
|
|
|
|
|
| |
:strict
Conflicts:
activerecord/test/models/person.rb
|
|
|
|
| |
update the records we retrive from the association
|
|
|
|
| |
builder
|
|
|
|
| |
Don't instantiate two objects in collection proxy / find_or_instantiate_by
|
| |
|
|
|
|
| |
ids_reader method fixed, test added to has_many association (for PostgreSQL)
|
|
|
|
| |
allow reorder to affect eager loading correctly
|
|
|
|
|
| |
when fetching ids for a collection, bypass preloading
to avoid the unnecessary performance overhead
|
| |
|
|
|
|
| |
Allows two models to use the same table but have different primary keys.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
method.
|
|\
| |
| | |
association methods are now generated in modules
|
| | |
|
|/
|
|
| |
present but the record is unsaved
|
|
|
|
| |
Preserve SELECT columns on the COUNT for finder_sql when possible
|
|
|
|
|
|
|
|
|
| |
If a record is removed from a has_many :through, all of the join records
relating to that record should also be removed from the through
association's target.
(Previously the records were removed in the database, but only one was
removed from the in-memory target array.)
|
|
|
|
| |
Fixes #3425.
|
|
|
|
|
| |
Fixes creating records in a through association with a polymorphic source
type.
|
| |
|
|
|
|
| |
Fix: habtm doesn't respect select query method
|
|
|
|
| |
Closes #3104.
|
|
|
|
| |
mutating the array. Fixes #3020.
|
|
|
|
| |
association scope.
|
|
|
|
| |
model should not be included in the association scope. (We're already excluding includes.) Fixes #2834.
|
|
|
|
| |
HasManyAssociation#inverse_updates_counter_cache?. Fixes #2755, where a counter cache could be decremented twice as far as it was supposed to be.
|
|
|
|
| |
have been failing intermittently for a long while due to what appears to be a Ruby bug. If anyone has the skills/expertise/time to debug this, please speak to the Travis guys.
|
| |
|
|
|
|
| |
therefore counted by the alias tracker. This is because the association_joins are aliased on initialization and then the tables are cached, so it is no use to alias the join_nodes later. Fixes #2556.
|
|
|
|
| |
loaded. Fixes #2054.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were experiencing CI test failures, for example:
* 3-1-stable: http://travis-ci.org/#!/rails/rails/builds/79473/L407
* master: http://travis-ci.org/#!/rails/rails/builds/79507/L80
These failures only happened on 1.8.7-p352, and we were only able to
reproduce on the Travis CI VM worker. We even tried creating a new 32
bit Ubuntu VM and running the tests on that, and it all worked fine.
After some epic trial and error, we discovered that replacing the
following:
fuu = Marshal.load(Marshal.dump(fuu))
with:
marshalled = Marshal.dump(fuu)
fuu = Marshal.load(marshalled)
seemed to prevent the failure.
We have NO IDEA why this is. If anyone has some great insight to
contribute then that is welcome. Otherwise, hopefully this will just
help us get the CI green again.
Many thanks to @joshk for help with sorting this out.
|
| |
|