On Tuesday, August 19, 2014 1:49:14 AM UTC-7, Steve Robinson wrote: > > > > On Tuesday, August 19, 2014 6:16:26 AM UTC+5:30, Phil wrote: >> >> >> While it can be 'rare' that somebody might run into this, I'd still argue >> that significant performance gains of caching associations like this is >> also rare/minimal (would be interesting to test). I'd rather lean towards >> data accuracy than speed, at least in my case. >> >> I'd simply like a simple config option to turn on/off this feature. I'd >> also suggest that it could even be dangerous to have on by default if >> things have to be done in particular ways to get around the potential pit >> falls, but I'd just be happy to have a config option to turn it off. >> >> Thanks for the reply! >> >> >> Phil >> >> On Monday, August 18, 2014 5:25:58 AM UTC-7, Jim wrote: >>> >>> It's not a systemic integrity problem, it is the way Rails has always >>> worked. Using tp.test_children.create() is not "another work-around", it >>> is the recommended way of adding children to a parent model that you have >>> already instantiated and has been available for as long as I can remember >>> (at least since rails 2.0.x). >>> >>> Scenarios where you would actually need to re-query the database *every >>> time you access a relation* are rare. If you really need to, you have that >>> option, but in no way should that be a default. >>> >>> Jim >>> >>>> >>>>> > > Hi, > > I disagree with you on your statement - "significant performance gains of > caching associations like this is also rare/minimal". > Almost all the apps that I've built had pages where I've used the same > association so many times for rendering the view and disabling caching in > those cases would be an absolute performance disaster! Think of all the > other problems it can cause... eager loading of associations? > > Well like Jim said its very rare that someone has to do what you're doing > and even if they have to do it, Rails has a way of doing it properly :) > > Thanks! >
Thanks for the reply Steve! I guess it's hard to say what the advantages are without testing... Assuming you are already indexing all of your id and *_id database columns and SQL query caching is on, I'm not sure what advantages association caching is actually providing. A test might be to edit collection_association.rb from the gem manually to set force_refresh = true and do some benchmarking (which I'd like to do when I get some time). Ironically, 37 Signals has some very good articles on how to do caching properly without worrying about getting stale data, this is a basic example: https://signalvnoise.com/posts/3113-how-key-based-cache-expiration-works I'm not sure what you mean by the 'rails way' in this case. Usually the rails way means not having to worry about cache management by default. In my case I have a mailer that simply looks like this: def customer_receipt(order) In the view it does @order.line_items and they are sometimes wrong. This just feels like an ugly hack to try to make rails faster during the days when ruby was really, really, slow (thankfully the latest since 2.0.0 is MUCH faster). Phil -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/b13730ea-e15e-4872-90ff-625015bcf69f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
