| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For example, you need to change this:
class Author < ActiveRecord::Base
has_many :posts
has_many :taggings, :through => :posts
end
class Post < ActiveRecord::Base
has_one :tagging
has_many :taggings
end
class Tagging < ActiveRecord::Base
end
To this:
class Author < ActiveRecord::Base
has_many :posts
has_many :taggings, :through => :posts, :source => :tagging
end
class Post < ActiveRecord::Base
has_one :tagging
has_many :taggings
end
class Tagging < ActiveRecord::Base
end
|
| |
|
|
|
| |
of using +inverse_of: false+ option. Changing the documentation and
adding a CHANGELOG entry for the automatic inverse detection feature.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When removing records from a `has_many` association it used
the `primary_key` defined on the association.
Our test suite didn't fail because on all occurences of `:primary_key`,
the specified column was available in both tables. This prevented the
code from raising an exception but it still behaved badly.
I added a test-case to prevent regressions that failed with:
```
1) Error:
HasManyAssociationsTest#test_has_many_assignment_with_custom_primary_key:
ActiveRecord::StatementInvalid: SQLite3::SQLException: no such column: essays.first_name: UPDATE "essays" SET "writer_id" = NULL WHERE "essays"."writer_id" = ? AND "essays"."first_name" IS NULL
```
|
| |
|
|
|
|
|
| |
According to
https://github.com/rails/rails/blob/b601399b72ab56cc01368f02615af99f45d1
4f02/activerecord/lib/active_record/counter_cache.rb#L14, u can pass
more then one association to the `reset_counters` method.
|
| |
|
|
|
|
| |
the results. Added tests to check to make sure that inverse associations are
automatically found when has_many, has_one, or belongs_to associations
are defined.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using symbol keys, ActiveRecord will now translate aliased attribute names to the actual column name used in the database:
With the model
class Topic
alias_attribute :heading, :title
end
The call
Topic.where(heading: 'The First Topic')
should yield the same result as
Topic.where(title: 'The First Topic')
This also applies to ActiveRecord::Relation::Calculations calls such as `Model.sum(:aliased)` and `Model.pluck(:aliased)`.
This will not work with SQL fragment strings like `Model.sum('DISTINCT aliased')`.
Github #7839
*Godfrey Chan*
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See #9869 and #9929.
The problem arises from the following example:
class Project < ActiveRecord::Base
scope :completed, -> { where completed: true }
end
class MajorProject < Project
end
When calling:
MajorProject.where(tasks_count: 10).completed
This expands to:
MajorProject.where(tasks_count: 10).scoping {
MajorProject.completed
}
However the lambda for the `completed` scope is defined on Project. This
means that when it is called, `self` is Project rather than
MajorProject. So it expands to:
MajorProject.where(tasks_count: 10).scoping {
Project.where(completed: true)
}
Since the scoping was applied on MajorProject, and not Project, this
fails to apply the tasks_count condition.
The solution is to make scoping apply across STI classes. I am slightly
concerned about the possible side-effects of this, but no tests fail and
it seems ok. I guess we'll see.
|
| | |
|
| |
|
|
| |
fixes #10016
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
The similarity of `Relation#uniq` to `Array#uniq` is confusing. Since our
Relation API is close to SQL terms I renamed `#uniq` to `#distinct`.
There is no deprecation. `#uniq` and `#uniq!` are aliases and will continue
to work. I also updated the documentation to promote the use of `#distinct`.
|
| |\
| |
| |
| |
| |
| |
| | |
Fix ActiveRecord `subclass_from_attrs` when eager_load is false.
Conflicts:
activerecord/CHANGELOG.md
|
| | |
| |
| |
| |
| | |
It cannot find subclass because all classes are loaded automatically
when it needs.
|
| |/
|
|
| |
Closes #9110
|
| |
|
|
| |
closes #9201
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Allow store accessors to be overrided like other attribute methods,
e.g.:
class User < ActiveRecord::Base
store :settings, accessors: [ :color, :homepage ], coder: JSON
def color
super || 'red'
end
end
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
because of an ambiguous column name. This happened if the association
model had a default scope that referenced a third table, and the third
table also referenced the original table (with an identical
foreign_key).
Mysql requires that ambiguous columns are deambiguated by using the full
table.column syntax. Postgresql and Sqlite use a different syntax for
updates altogether (and don't tolerate table.name syntax), so the fix
requires always including the full table.column and discarding it later
for Sqlite and Postgresql.
|
| | |
|
| |
|
|
|
|
| |
This reverts commit 4e05bfb8e254c3360a3ca4a6cb332995314338fe.
Reason: BlankTopic#blank? should not be removed to check that dynamic finder with a bang can find a model that responds to `blank?`
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The native JSON library bypasses the `to_json` overrides in
active_support/core_ext/object/to_json.rb by calling its native
implementation directly. However `ActiveRecord::Store` uses a
HWIA so `JSON.dump` will call our `to_json` instead with a
`State` object for options rather than a `Hash`. This generates
a warning when the `:encoding`, `:only` & `:except` keys are
accessed in `Hash#as_json` because the `State` object delegates
unknown keys to `instance_variable_get` in its `:[]` method.
Workaround this warning in the test by using a custom coder that
calls `ActiveSupport::JSON.encode` directly.
|
| |\
| |
| |
| |
| | |
seejee/regression_test_for_chained_preloaded_scopes
Added test case to prevent regression of chained, preloaded scopes.
|
| | | |
|
| |\ \
| | |
| | | |
Fix .update_all and .delete_all when using a condition on a joined table in a default_scope
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| | |
in a default_scope.
`Model.joins(...).where(condition_on_joined_table).update_all` /
`delete_all` worked, but the same operation implemented with a
default_scope generated a SQL error because ActiveRecord ignored the
join but implemented the where condition anyways.
|
| |/
|
|
|
|
|
| |
Suggested by @dhh.
It doesn't affect the generated SQL, so seems reasonable to continue to
allow it as an association option.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
For some reason postgresql doesn't pass an integer value to load.
cc @tenderlove
|
| |
|
|
| |
Fix #8575
|
| |
|
|
|
|
|
| |
This can be done using the class attribute cache_timestamp_format
Conflicts:
railties/guides/source/configuring.textile
|
| |
|
|
|
|
| |
Conflicts:
activerecord/test/models/bulb.rb
activerecord/test/schema/schema.rb
|
| |
|
|
| |
Closes #3313
|
| |
|
|
|
|
|
|
| |
Allows you to do BaseClass.new(:type => "SubClass") as well as
parent.children.build(:type => "SubClass") or parent.build_child
to initialize an STI subclass. Ensures that the class name is a
valid class and that it is in the ancestors of the super class
that the association is expecting.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
In the end I think the pain of implementing this seamlessly was not
worth the gain provided.
The intention was that it would allow plain ruby objects that might not
live in your main application to be subclassed and have persistence
mixed in. But I've decided that the benefit of doing that is not worth
the amount of complexity that the implementation introduced.
|
| | |
|
| |
|
|
|
| |
The counter column name in the intermediate model need to be access
via the through reflection.
|
| |
|
|
|
|
|
| |
This reverts commit 761bc751d31c22e2c2fdae2b4cdd435b68b6d783.
This commit wasn't fixing any issue just using the same table for
different models with different primary keys.
|
| | |
|
| | |
|
