A while ago there was a discussion on interpolate_sql() context in
associations that pointed out that when a :conditions is embedded in
an association declaration, the interpolate_sql() call that evaluates
the generated string (from sanitize_sql) can either be the
AssociationJoin (when eager loading) or the record that that the
association is defined on (for non-eager-loaded association
instantiation). This, essentially, makes the interpolation itself
almost completely useless unless one can guarantee that it will only
be called in one context or the other. And even more problematically,
sanitize_sql is evaluated in a different context (the reflection
class). So, there are a number of problems I''m working on resolving:
1) To be able to ensure the the table_name referenced in a
Hash :conditions (e.g. {:member_id => nil}) will be correct whether
loaded straight or eager-loaded such that there is table_name aliasing
involved (I think I''ve got this one done with a bit of monkey-patching
on AR::Base and AssociationJoin).
2) Currently there is no way (that I can find) to refer to the
association proxy, the reflection or the parent class of an
association reliably in the :conditions String. Again, the biggest
issue here is the aliasing of table_names in eager-loading, but there
may be other issues. The first fix above covers many cases, but if I
want to refer to two different fields in the association''s join table,
I just can''t. E.g.
has_many :source_memberships, {
:foreign_key => ''member_id'', :class_name =>
''Membership'',
:conditions => ''#{join_table}.group_id
#{join_table}.source_group_id'',
:include => [:member, :source_group, :group],
:order => ''memberships.created_at ASC''
}
So, questions? Does anyone know why interpolate_sql() is sent to the
@owner (in AssociationProxy) and not the @reflection.klass like
sanitize_sql? Has anyone else been frustrated by this, or do people
just not use association :conditions because of this? One strategy
would be to massage table names after the interpolate_sql when
aliasing. This is a bit dangerous though and I''d prefer some
standardized evaluation context.
Prev thread:
http://groups.google.com/group/rubyonrails-core/browse_frm/thread/e22d42849dc3fd7a/fb28386e25e66941
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---
leei wrote:> 1) To be able to ensure the the table_name referenced in a > Hash :conditions (e.g. {:member_id => nil}) will be correct whether > loaded straight or eager-loaded such that there is table_name aliasing > involved (I think I''ve got this one done with a bit of monkey-patching > on AR::Base and AssociationJoin).member_id could be a field in several of the joined tables, so how do you resolve the ambiguity?> 2) Currently there is no way (that I can find) to refer to the > association proxy, the reflection or the parent class of an > association reliably in the :conditions String. Again, the biggest > issue here is the aliasing of table_names in eager-loading, but there > may be other issues. The first fix above covers many cases, but if I > want to refer to two different fields in the association''s join table, > I just can''t. E.g. > > has_many :source_memberships, { > :foreign_key => ''member_id'', :class_name => ''Membership'', > :conditions => ''#{join_table}.group_id > #{join_table}.source_group_id'', > :include => [:member, :source_group, :group], > :order => ''memberships.created_at ASC'' > }Could you further explain the problem with two different fields.> So, questions? Does anyone know why interpolate_sql() is sent to the > @owner (in AssociationProxy) and not the @reflection.klass like > sanitize_sql? Has anyone else been frustrated by this, or do people > just not use association :conditions because of this? One strategy > would be to massage table names after the interpolate_sql when > aliasing. This is a bit dangerous though and I''d prefer some > standardized evaluation context.Yes, the availability of a consistent variable in both interpolation contexts, such as "association_table", would solve a lot of problems. My current solution is to avoid interpolation in these circumstances and change the :conditions option dynamically. -- We develop, watch us RoR, in numbers too big to ignore. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Mar 21, 4:37 am, Mark Reginald James <m...@bigpond.net.au> wrote:> leei wrote: > > 1) To be able to ensure the the table_name referenced in a > > Hash :conditions (e.g. {:member_id => nil}) will be correct whether > > loaded straight or eager-loaded such that there is table_name aliasing > > involved (I think I''ve got this one done with a bit of monkey-patching > > on AR::Base and AssociationJoin). > > member_id could be a field in several of the joined tables, so > how do you resolve the ambiguity?The key is that it should be "sanitized" against the class of the association, but with any table aliasing in effect at the time (from eager loading) used to specify the table name. Currently it is sanitized in the correct class, but without reference to any table name aliasing. My patch/plugin solves that.> > 2) Currently there is no way (that I can find) to refer to the > > association proxy, the reflection or the parent class of an > > association reliably in the :conditions String. Again, the biggest > > issue here is the aliasing of table_names in eager-loading, but there > > may be other issues. The first fix above covers many cases, but if I > > want to refer to two different fields in the association''s join table, > > I just can''t. E.g. > > > has_many :source_memberships, { > > :foreign_key => ''member_id'', :class_name => ''Membership'', > > :conditions => ''#{join_table}.group_id > > #{join_table}.source_group_id'', > > :include => [:member, :source_group, :group], > > :order => ''memberships.created_at ASC'' > > } > > Could you further explain the problem with two different fields.The issue is that if I specify the condition using a Hash (e.g. :group_id => ''#{join_table}.source_group_id'') then the group_id will be associated with the ''correct'' table (and with my patch, even in the presence of aliasing), but because the String is interpolated in the @owner context, it has no way of accessing either the reflection or association objects to get at the ''right'' table name. If the interpolation happened in the @sender (like the sanitize) then it would be easier to use the same solution as I used for the sanitize_sql, which was to temporarily override table_name.> > So, questions? Does anyone know why interpolate_sql() is sent to the > > @owner (in AssociationProxy) and not the @reflection.klass like > > sanitize_sql? Has anyone else been frustrated by this, or do people > > just not use association :conditions because of this? One strategy > > would be to massage table names after the interpolate_sql when > > aliasing. This is a bit dangerous though and I''d prefer some > > standardized evaluation context. > > Yes, the availability of a consistent variable in both interpolation > contexts, such as "association_table", would solve a lot of problems. > > My current solution is to avoid interpolation in these circumstances > and change the :conditions option dynamically.Huh? How do you do that? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> So, questions? Does anyone know why interpolate_sql() is sent to the > @owner (in AssociationProxy) and not the @reflection.klass like > sanitize_sql? Has anyone else been frustrated by this, or do people > just not use association :conditions because of this? One strategy > would be to massage table names after the interpolate_sql when > aliasing. This is a bit dangerous though and I''d prefer some > standardized evaluation context.We''re looking into completely rejigging the query generation in 2.2 by using something based on relational algebra rather than slinging strings around. That will make all this stuff about a billion times easier. My gut feeling is that the fix for this kind of issue is better handled in that work, rather than throwing a few more oddities into the current associations code :). However if there''s some simple fixes or enhancements we can do in the meantime, we can look at them each in turn. -- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---