Has_many :conditions =>

Rails
1

In a model class, can the target of the has_many :conditions option be a
method? For example:

class etc.

has_many abcs :conditions => :local_conditions

private

def local_conditions
[ “start = :begin_date AND end = :end_date”,
{ :begin_date => “2008-01-01”, :end_date => DateTime.now } ]
end

end

2

On 5 May 2008, at 21:16, James B. wrote:

In a model class, can the target of the has_many :conditions option
be a
method? For example:

class etc.

has_many abcs :conditions => :local_conditions

Not quite like that. But those conditions are interpolated in the
context of the model, so for example you can say
:conditions => ‘start_date > #{@start_date}’

When the association is fetched that will be interpolated in the
context of the model. You probably could write
:conditions => ‘#{local_conditions}’

as long as local conditions returned a string of sql (ie not a hash as
shown below)

Fred

3

James B. wrote:

Is there aw way to do this?

Never mind. I completely misunderstood the example given. I will try
this out and report back.

Thanks again.

4

I must be missing something obvious.

If I have

class Model < AR

has_many abcs :conditions => [ “start = :start_date”,
{ :start_date => DateTime.now } ]

Then this assigns an array to the :conditions key, correct?

Is there no way to pass a variable that represents an array with the
exact same content to :conditions such that the array contents are
assigned to the key?

5

James B. wrote:

Is there no way to pass a variable that represents an array with the
exact same content to :conditions such that the array contents are
assigned to the key?

I can get it to work this way:

class Model etc.

@@active_row = [ “start <= :start_date”, { :start_date => DateTime.now
} ]

has_many abcs :conditions => @@active_row

Is there a better/cleaner idiom that works?

6

Frederick C. wrote:

Not quite like that. But those conditions are interpolated in the
context of the model, so for example you can say
:conditions => ‘start_date > #{@start_date}’

When the association is fetched that will be interpolated in the
context of the model. You probably could write
:conditions => ‘#{local_conditions}’

as long as local conditions returned a string of sql (ie not a hash as
shown below)

Fred

Well, yes. I had that working in that exact fashion. The situation that
I am now trying to address is I have a large number of associations in
serveral models that will share identical conditional SQL fragments and
I would like to store these in a single module and call them wherever
required.

Is there aw way to do this?

7

Hi –

On Mon, 5 May 2008, James B. wrote:

@@active_row = [ “start <= :start_date”, { :start_date => DateTime.now
} ]

has_many abcs :conditions => @@active_row

Keep in mind, though, that that will evaluate DateTime.now when it
loads the model file, and (depending on what environment you’re in,
etc.) may not do it again.

Is there a better/cleaner idiom that works?

Good question. I can’t think of one that doesn’t stringify the
argument, which makes an array useless. That’s not to say there isn’t
a way… but I haven’t come up with it.

David

–
Rails training from David A. Black and Ruby Power and Light:
INTRO TO RAILS June 9-12 Berlin
ADVANCING WITH RAILS June 16-19 Berlin
INTRO TO RAILS June 24-27 London (Skills Matter)
See http://www.rubypal.com for details and updates!

8

Hi –

On Tue, 6 May 2008, James B. wrote:

variable in this specific case or is this a general trait deriving from
the manner in which Rails caches db calls?

It’s just a matter of how Ruby parses your file. What you’ve got is:

class Model

@@active_row = [ “start <= :start_date”,
{ :start_date => DateTime.now } ]

has_many :abcs, :conditions => @@active_row

end

When the file is read in and executed, a value will be assigned to the
class variable @@active_row. Then, the method has_many will be
executed, with the arguments :abc and { :conditions => [“start <=
:start_date”, { :start_date <= “2008-05-05 21:43:47” } ] } (assuming
that’s the date and time at that moment). That string won’t change
(unless there’s a reload). So every time you do:

m = Model.find(x)
abcs = m.abcs

you’ll be constraining the abcs collection as being <= 2008-05-05
21:43:47.

David

–
Rails training from David A. Black and Ruby Power and Light:
INTRO TO RAILS June 9-12 Berlin
ADVANCING WITH RAILS June 16-19 Berlin
INTRO TO RAILS June 24-27 London (Skills Matter)
See http://www.rubypal.com for details and updates!

9

David A. Black wrote:

Hi –

On Tue, 6 May 2008, James B. wrote:

variable in this specific case or is this a general trait deriving from
the manner in which Rails caches db calls?

It’s just a matter of how Ruby parses your file. What you’ve got is:

I infer from this that finders containing dynamic selection elements
have to go into the controllers, or does the same problem arise there as
well?

10

David A. Black wrote:

Keep in mind, though, that that will evaluate DateTime.now when it
loads the model file, and (depending on what environment you’re in,
etc.) may not do it again.

Is this a consequence of using a class variable rather than an instance
variable in this specific case or is this a general trait deriving from
the manner in which Rails caches db calls?

11

Hi –

On Tue, 6 May 2008, James B. wrote:

I infer from this that finders containing dynamic selection elements
have to go into the controllers, or does the same problem arise there as
well?

You can have a finder method that does this (or some variation on this
– it’s just an example):

def find_earlier_things
self.class.find(:all, :conditions => […])
end

where the … includes DateTime stuff, and then when you do
thing.find_earlier_things, it will go find them and, since the method
is being executed, it will evaluated the conditions array on the spot.
The problem with the association situation is that the association
(has_many) is itself a method, and it only gets called once – at
which point it has to have its arguments in place. The only way to
have the arguments update themselves later would be to have one of
them be an executable object (Proc or method), and I don’t think
there’s a way to insinuate one into the conditions position (though if
I’m wrong, or if it’s been added recently and I haven’t noticed, I’d
be glad to be corrected).

David

–
Rails training from David A. Black and Ruby Power and Light:
INTRO TO RAILS June 9-12 Berlin
ADVANCING WITH RAILS June 16-19 Berlin
INTRO TO RAILS June 24-27 London (Skills Matter)
See http://www.rubypal.com for details and updates!

12

Hi –

On Tue, 6 May 2008, Frederick C. wrote:

be glad to be corrected).

The only way I’m aware of is the interpolation trick (:conditions =>
‘#{something to evaluate later}’). If you use sanitize_sql you can
probably keep on using hash conditions & stuff.

I had given up on ‘#{}’ because of the problem of having it mush
arrays and hashes together for string representation – but you’re
quite right that there’s an escape clause…

So here’s what I’ve got in my little testbed:

def self.sanitize_me(array)
sanitize_sql(array)
end

has_many :items,
:conditions => ‘#{self.class.sanitize_me([“created_at > ?”,
Time.now])}’

The extra method is because sanitize_sql is protected. Next cup of
coffee may or may not produce a way to avoid that rather inelegant
workaround :slight_smile: (There’s ‘send’, of course.)

David

–
Rails training from David A. Black and Ruby Power and Light:
INTRO TO RAILS June 9-12 Berlin
ADVANCING WITH RAILS June 16-19 Berlin
INTRO TO RAILS June 24-27 London (Skills Matter)
See http://www.rubypal.com for details and updates!

13

On 6 May 2008, at 03:49, David A. Black wrote:

is being executed, it will evaluated the conditions array on the spot.
The problem with the association situation is that the association
(has_many) is itself a method, and it only gets called once – at
which point it has to have its arguments in place. The only way to
have the arguments update themselves later would be to have one of
them be an executable object (Proc or method), and I don’t think
there’s a way to insinuate one into the conditions position (though if
I’m wrong, or if it’s been added recently and I haven’t noticed, I’d
be glad to be corrected).

The only way I’m aware of is the interpolation trick (:conditions =>
‘#{something to evaluate later}’). If you use sanitize_sql you can
probably keep on using hash conditions & stuff.

Fred

14

David A. Black wrote:

So here’s what I’ve got in my little testbed:

def self.sanitize_me(array)
sanitize_sql(array)
end

has_many :items,
:conditions => ‘#{self.class.sanitize_me([“created_at > ?”,
Time.now])}’

When I try this on edge rails then I get this:

@entity = Entity.find(1)
NoMethodError: undefined method sanitize_me' for Class:Class from /home/byrnejb/Software/Development/Projects/proforma/app/models/entity.rb:47 from /home/byrnejb/Software/Development/Projects/proforma/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:203:inload_without_new_constant_marking’

15

James B. wrote:

David A. Black wrote:

So here’s what I’ve got in my little testbed:

def self.sanitize_me(array)
sanitize_sql(array)
end

has_many :items,
:conditions => ‘#{self.class.sanitize_me([“created_at > ?”,
Time.now])}’

I did this instead:

has_many :items,
:conditions => “#{sanitize_sql([
“created_at > :time_now”, { :time_now => DateTime.now }
])}”

This throws no errors but, the time value is fixed at the time of first
load for all instances.

16

On 6 May 2008, at 15:32, Frederick C. wrote:

class is loaded and not later on.
Forgot to say, that’s also why david’s trick wasn’t working (because
that assumes that it is being evaluated in the context of an instance
of the class, but by swapping the quotes you make it evaluate at load
time and thus in the context of the class)

Fred

17

On 6 May 2008, at 15:21, James B. wrote:

:conditions => "#{sanitize_sql([
   "created_at > :time_now", { :time_now => DateTime.now }
                ])}"

The crucial difference is that you are using double quotes and not
single quotes. That is why your conditions are evaluated when the
class is loaded and not later on.

Fred

18

Frederick C. wrote:

On 6 May 2008, at 15:21, James B. wrote:

:conditions => "#{sanitize_sql([
   "created_at > :time_now", { :time_now => DateTime.now }
                ])}"

The crucial difference is that you are using double quotes and not
single quotes. That is why your conditions are evaluated when the
class is loaded and not later on.

Fred

Well, I would never have realized that problem on my own. However, when
I change the outer " to ’ then I always throw and undefined method
error.

…
def self.sql_sanitize_here(array)
sanitize_sql(array)
end
…
has_one :active_client, :class_name => ‘Client’,
:conditions => ‘#{self.class.sanitize_sql_here([
" effective_from <= :date_today
AND ( superseded_after > :date_today OR
superseded_after IS null ) ",
{ :date_today => DateTime.now } ])}’

@entity.active_client
NoMethodError: undefined method sanitize_sql_here' for #<Class:0xb7558edc> from /home/byrnejb/Software/Development/Projects/proforma/vendor/rails/activerecord/lib/active_record/base.rb:2550:ininterpolate_sql’
from (eval):1:in interpolate_sql' from /home/byrnejb/Software/Development/Projects/proforma/vendor/rails/activerecord/lib/active_record/associations/association_proxy.rb:139:insend’

19

Frederick C. wrote:

On 6 May 2008, at 15:52, James B. wrote:

…
has_one :active_client, :class_name => ‘Client’,
:conditions => '#{self.class.sanitize_sql_here([

These need to match. You’ve defined sql_sanitize_here but are using
sanitize_sql_here

Fred

Arrgggh!

Yes, this now works. Many thanks for your assistance.

20

Now that this is working I wish to get the code out of the association
and put it in one place where I can easily reuse it across models and
associations. Is this possible?

One thought that I had earlier envisaged creating a virtual attribute on
the Client model called active? and putting the code in there but, this
fails on two counts: 1, the presence of a ? in the method name causes
problems with the SQL engine in sqlite3 ( I have not tested this on
PostgreSQL); and 2, virtual attributes cannot of course be evaluated
during the SQL call (although one could argue that the association
finders should in fact go through the dependent class and do exactly
that because this sort of logic belongs in the model directly providing
the where parameters).

It seems that the tidiest solution from the standpoint of rails coding
and maintenance is to simply add an column named active of type boolean
to the model and set it to true or false in accordance with the values
in effective_date and superseded_date, which seems a bit redundant but
easier to check.

Comments?