The new find method in the svn trunk attempts to fix this with eager
loading. In your example, you might do this:
class Miner
has_one :gold_claim
class GoldClaim
belongs_to :miner
@miners = Miner.find :all, :include => :gold_claim
or
@gold_claims = GoldClaim.find :all, :include => :miner
I happened to be in #rubyonrails when nextangle announced this a
little while ago, so I''ve been playing around with it. The RDocs
don''t have much, but I''ve been looking through the source to
find the
available options.
@miners = Miner.find :all, :include => :gold_claim, :conditions =>
''present = 1'', :order => ''name DESC''
I have an app with heavily modified queries and piggybacking (as you
mentioned in #2). I started from scratch using the new Find method,
and now I don''t have that n+1 queries problem.
On 4/15/05, Leonardo Francalanci
<lfrancalanci-UEawqlgQ9KpeoWH0uzbU5w@public.gmane.org>
wrote:> Hello,
> I''m a Java developer and I''m looking at Rails as a very
interesting thing.
>
> I read the article
> http://theserverside.com/articles/article.tss?l=RailsHibernate
> and saw a couple of things that I didn''t like too much:
>
> 1) The N+1 problem
>
> This has been discussed in the thread (or should I say "flame"?)
"Java
> people want to beat us". It seems (from the thread) that something
will
> be done in the future to change this, so I won''t discuss it again:
the
> important is that something will be changed!
>
> 2) The "everything becomes part of the upper object" thing
(sorry,
> couldn''t find another way to name the problem). From the article:
>
> <snip>
> @minersWithSqA = Miner.find_by_sql [
> "SELECT m.*, g.square_area FROM gold_claims g, miners m
" +
> " WHERE g.square_area = ? and m.gold_claim_id = g.id",
1000]
>
> The big thing to realize is that since Rails classes have dynamic
> fields, all columns returned by the result set are smashed on the Miner
> object. In the last query, the Miner gets a square_area field that it
> doesn''t normally get. This means the view might have to change,
like so...
>
> # Normal association traversing
> <%= miner.gold_claim.square_area
>
> # Altered query for @minersWithSqA
> <%= miner.square_area %>
> </snip>
>
> That is, I can''t access the "square_area" property using
the proper
> object (gold_claim), but I have to use "miner". I have to
remember in
> that specific view that "square_area" doesn''t belong to
"gold_claim",
> but to "miner". In other words, the "gold_claim" object
associated to
> the "miner" doesn''t exist at all in this case!
>
> Is this correct? If yes: will this behaviour be changed sometime?
>
> PLEASE don''t take this post as a flame-starting-post. I
didn''t like what
> happened to the "Java people want to beat us". I''m not
saying something
> like "Java is better than Ruby On Rails". I just didn''t
say all the
> things I like in Rails that I don''t like in Java ;)
>
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
--
rick
http://techno-weenie.net