The only solution that has been suggested to me is to traverse the readings directly, which is sort of missing the entire point of the :through relationship. In that case, I basically have to rewrite the logic that rails is supposed to be doing for me with the :through concept, by iterating over all of the readings and screening out only that subset with the reader_id I care about.

I see discussion in some pages found through my googling that the has_and_belongs_to_many method has a deprecated feature that allows you to mess with attributes on the join table (push_with_attributes). I don't think what I am trying to is particularly novel. Even just getting the ID of the record in the join table that connected this article to this reader would be enough or me to subsequently get at the attributes of the join table that I care about.

Re: Accessing attributes on join table?

I don't understand the problem. You can't call reader.article because each reader has_many articles. You would need to iterate through the given articles in the first place, so it's really no different to iterate through the readings and then fetch the article through that.

That would produce a nice list of the reader's favorite articles. The underlying query to the database for a list of matching records in the "readings" table to match a particular value of person_id and favorite would have been performed exactly once.

However, if you want to show the reader's remarks, you need to do the query differently. Everyone tells me the only way to get at any attribute of the join table is to traverse the join table directly -- i.e. I cannot get at attributes of the join table merely by referencing some item was accessed through that very join relationship. Consider the code we need to write in order to show the view of a reader's favorite articles, including the remarks that reader recorded for a given reading:

The moral of the story here seems to be that if you have any sort of interesting attribute you want to access in the join record, it is pointless to define some sort of conditions-based thing like ":favorite_articles" in our Reader model, because you are simply going to rewrite the SQL yourself later on, i.e. you will never use the ":favorite_articles" construct if you end up needing to access an attribute of the join table. That is, unless you want to repeat yourself.

I guess that is what I was getting at. Maybe I am completely wrong, in which case apologies for being a newbie. But what I had been hoping was that since by definition an individual favorite_article from Reader.favorite_articles (through readings) came into being through a specific join, I might get some shortcut way of accessing that join record and hence writing much cleaner code along the following lines:

Where "something here" would be a shorthand way of saying, look, the very existence of favorite_article is as a result of some record in the intermediate join table ("readings"), so give me a reference to that record... And remember, Readings.find(:all, :conditions=>...) won't work in place of "[something here]" because the same person can read the same article multiple times, with different remarks each time.

Re: Accessing attributes on join table?

And remember, Readings.find(:all, :conditions=>...) won't work in place of "[something here]" because the same person can read the same article multiple times, with different remarks each time.

At first I was going to suggest creating a favorite_readings (instead of favorite_articles), but after reading your last statement I see why this would not work.

From my understanding, if the reader has many remarks for the same article, you only want to display the title of the article once and list the remarks below that. This means you will need to iterate through the remarks/readings for each article. Something like this should work:

This will probably result in another query to the database so you may want to optimize that by looping through the already found readings and returning any for the given reader.

I understand if this entire solution is not satisfactory, but I don't see how there could be a better way. The article itself doesn't have any knowledge as to which reader it was fetched through, and that's how it should be IMO. I don't think a model's state should change depending upon how it is fetched.