I ve defined the following relation in one of my models with a dynamic
where condition:
has_one :selection,
:foreign_key => 'object_id',
:conditions => 'selection_type = 1 and account_id = #
{self.send(:account_id)}'
That works perfect, however when I try to eager load that relation I
am getting the following error when doing a count. Seems that self is
not really my model class anymore.... Does anybody know how I can get
that up and running?
I ve defined the following relation in one of my models with a dynamic
where condition:
has_one :selection,
:foreign_key => 'object_id',
:conditions => 'selection_type = 1 and account_id = #
{self.send(:account_id)}'
That works perfect, however when I try to eager load that relation I
am getting the following error when doing a count. Seems that self is
not really my model class anymore.... Does anybody know how I can get
that up and running?
When you do a 'normal' load the conditions are interpolated in the
context of the appropriate instance, but when you do an eager load
that can't happen (because the object is not loaded yet (so account_id
is not known) or because you are loading multiple record) so the
conditions are evaluated in the context of the class. You just can't
eager load stuff with that sort of interpolated condition, although I
suppose you might be able to put together a separate association,
purely for eager loading, where the conditions would become account_id
= parent_objects.account_id.
I ve defined the following relation in one of my models with a dynamic
where condition:
has_one :selection,
:foreign_key => 'object_id',
:conditions => 'selection_type = 1 and account_id = #
{self.send(:account_id)}'
That works perfect, however when I try to eager load that relation I
am getting the following error when doing a count. Seems that self is
not really my model class anymore.... Does anybody know how I can get
that up and running?
Any dynamic change to the conditions of an association
would be common to all Rails handlers associated with that
process. Prior to Rails 2.2, this is was always one, so
there was no problem. But if you use Rails in multi-threaded
mode, one thread could change the conditions used by another
thread before those conditions are built into a DB query.
So you'd either have to put an exclusive lock around
that query (which may have a significant impact on the
database parallelism), or rewrite the AR code to fork
a thread-private condition whenever one is dynamically
set.
However, I m really interested in this topic.
Maybe you can explain me the proposed "rails way" to accomplish for
example a relation which depends on the currently logged in user (just
as an example)....
