This repository is private.
All pages are served over SSL and all pushing and pulling is done over SSH.
No one may fork, clone, or view it unless they are added as a member.
Every repository with this icon (
) is private.
Every repository with this icon (
This repository is public.
Anyone may fork, clone, or view it.
Every repository with this icon (
) is public.
Every repository with this icon (
commit cd994eff9a343df376bfaec59de5b24a2ab51256
tree f18d158c5d11cbba33784a136b0276f8237c6a8b
parent 582bff71c465075d01b6e062d64b13ac3df4ad56
tree f18d158c5d11cbba33784a136b0276f8237c6a8b
parent 582bff71c465075d01b6e062d64b13ac3df4ad56
... |
... |
|
... |
... |
|
... |
... |
|












Hi,
Cool. This is very useful because it allows me to not have to worry about the name of the table when I join to a table and then back again, eg. like finding another book on the same bookshelf:
Books.all( :joins => {:bookshelf => :books}, :conditions => {:bookshelves => {:books => {:title => ‘Another Book on the Same Shelf’}}} )
Without having to worry about the name of the second book table in the SQL like I used to. So thanks!
I have 2 suggestions, though.
But overall, very useful. ben
Actually, sorry to be a pain, but the above seems to actually illustrate a bug. Say I’m trying to get the names of all the books on a particular shelf (which are book1 and book2), and all I have is the name of one of the books (book1).
Using your method, I would
I end up getting<pre> => ["book1", "book1"] </pre>I suppose this is a bug, but I’m too lazy to file it on lighthouse.
bug report:
http://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/710-condition-hashes-through-joins-gives-fails-when-circular-references-are-used
Thanks Pratik