Forum: Ruby on Rails AR.find :include is adding stuff I don't want

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Greg W. (Guest)
on 2009-04-08 08:35
In this code below, ActiveRecord returns data from associations I don't
want.

class Article < ActiveRecord::Base

  has_many  :extras
  has_many  :pages, :order => 'sortOrder'
  has_many  :assets

  def get_list
    return self.find(:all,
      :include    => :extras,
      :conditions => ["publishable='Y'"])
  end
end

Without the :include statement, we get the usual lazy load, and no
associations are loaded, only the attributes of the Article.

However, I want data from the :extras association and not the others.

When I use the code above, I get data from Article (good), Extras
(good), and Assets (bad), and nothing from Pages (curious).

I don't understand why Assets is being included, and I don't know how to
keep that data out of the results.

What am I missing? Thx.

-- gw
Frederick C. (Guest)
on 2009-04-08 11:19
(Received via mailing list)
On Apr 8, 5:35 am, Greg W. <removed_email_address@domain.invalid>
wrote:

> When I use the code above, I get data from Article (good), Extras
> (good), and Assets (bad), and nothing from Pages (curious).
>
> I don't understand why Assets is being included, and I don't know how to
> keep that data out of the results.
>

Odd. Maybe you could show the sql it is executing ?

Fred
Greg W. (Guest)
on 2009-04-08 12:52
Frederick C. wrote:
> On Apr 8, 5:35�am, Greg W. <removed_email_address@domain.invalid>
> wrote:
>
>> When I use the code above, I get data from Article (good), Extras
>> (good), and Assets (bad), and nothing from Pages (curious).
>>
>> I don't understand why Assets is being included, and I don't know how to
>> keep that data out of the results.
>>
>
> Odd. Maybe you could show the sql it is executing ?

Hmm. now I am seeing something different.

With this code (more verbatim this time).......

class Article < ActiveRecord::Base

  self.primary_key = 'rcrd_id'

  has_many  :extras,
            :dependent => :destroy

  has_many  :pages,
            :order => 'sortOrder',
            :dependent => :destroy

  has_many  :assets,
            :dependent => :destroy

  def self.get_list
    list = self.find(:all,
      :include => [:extras],
      :conditions => [
        "#{self.table_name}.rcrd_status='Y' AND ready='Y' AND
publishDate <= :today",
        {:today => Date.today.to_s} ])
  end
end

Or with this code......

def self.get_list
  list = self.find(:all,
    :conditions => [
      "#{self.table_name}.rcrd_status='Y' AND ready='Y' AND publishDate
<= :today",
      {:today => Date.today.to_s} ])
end

I now see these same queries in the log.....
(and this is restarting Rails after each time I change the code, just to
be sure)

  Article Load (1.6ms)   SELECT * FROM `articles`
WHERE (articles.rcrd_status='Y' AND ready='Y' AND publishDate <=
'2009-04-08') 
  Asset Load (0.8ms)   SELECT * FROM `assets` WHERE
(`assets`.article_id = 'abc123') 
  Extra Load (1.1ms)   SELECT * FROM `extras` WHERE
(`extras`.article_id = 'abc123') 

I know it was different before, I even showed someone to confirm it.

I don't see anything odd about the other models, they both have a simple
belongs_to articles statement, and nothing else. Pages has a belongs_to
articles, and a has_many to another model. Maybe that keeps pages from
being loaded?

So, I dunno. But shouldn't that second finder case (without :include)
not be returning :assets nor :extras? I end up using debug() to output
the results to confirm what is actually being loaded, and I get those
two associations, but no :pages data. Seems weird.

-- gw
Frederick C. (Guest)
on 2009-04-08 13:06
(Received via mailing list)
On Apr 8, 9:52 am, Greg W. <removed_email_address@domain.invalid>
wrote:
> Frederick C. wrote:
> > On Apr 8, 5:35 am, Greg W. <removed_email_address@domain.invalid>
> > wrote:

> So, I dunno. But shouldn't that second finder case (without :include)
> not be returning :assets nor :extras? I end up using debug() to output
> the results to confirm what is actually being loaded, and I get those
> two associations, but no :pages data. Seems weird.
>
Random question: are you doing this from the console or is this output
from an app. Are you sure the load is coming from the find and not
from the association been accessed subsequently (eg put a log
statement after the find(..., :include) ? )

Fred
Greg W. (Guest)
on 2009-04-08 13:44
Frederick C. wrote:
> On Apr 8, 9:52�am, Greg W. <removed_email_address@domain.invalid>
> wrote:
>> Frederick C. wrote:
>> > On Apr 8, 5:35 am, Greg W. <removed_email_address@domain.invalid>
>> > wrote:
>
>> So, I dunno. But shouldn't that second finder case (without :include)
>> not be returning :assets nor :extras? I end up using debug() to output
>> the results to confirm what is actually being loaded, and I get those
>> two associations, but no :pages data. Seems weird.
>>
> Random question: are you doing this from the console or is this output
> from an app. Are you sure the load is coming from the find and not
> from the association been accessed subsequently (eg put a log
> statement after the find(..., :include) ? )


@#$#! After writing a big long thing to prove there was no other action
taking place, and taking one more wider look before sending it to be
sure I wasn't making an idiot of myself, I just scrolled down a little
further in the model to re-discover an after_find I wrote which would in
fact touch assets & extras.

I had just so compartmentalized the :include thing in my mind, I wasn't
remembering after_find.

Egads. So sorry to waste your time Fred. But proving there was no log
statement question pushed me to at least solve the (not so puzzling)
puzzle. Thanks.

-- gw
Frederick C. (Guest)
on 2009-04-08 13:52
(Received via mailing list)
On 8 Apr 2009, at 10:44, Greg W. wrote:
> wasn't
> remembering after_find.
>
> Egads. So sorry to waste your time Fred. But proving there was no log
> statement question pushed me to at least solve the (not so puzzling)
> puzzle. Thanks.

D'oh! Happens to all of us :-)

Fred
This topic is locked and can not be replied to.