Tuesday, August 19, 2014
On Tuesday, August 19, 2014 9:01:36 PM UTC-4, Phil wrote:
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).
If your dataset is small and properly indexed, and you have very few related items, chances are you will see very little change in performance from reloading every time you access the order line items. If you have several hundred line items, things may be a little different. If your database is on a different machine than the web server, things may also be a little different.
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:
Ironically, this has nothing to do with what you are having problems with. You will still have the "stale" object. (Unless you are suggesting that Rails should check the updated_at for every ActiveRecord object every single time you access it. In that case, good luck. I doubt you will ever find any ORM so poorly written.)
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.
I don't worry about cache management by default. In addition, I don't have to worry about how to start using the database caching, and when I might need it.
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).
If your order line items are wrong, that is because somewhere in the code, somebody made some incorrect assumptions and wrote some incorrect code, examples of which have already been pointed out. Thankfully, the goal of the framework is *not* to make sure that can never happen by default, with the side effect that you may need to make drastic changes to the code if you ever want to start caching. The framework does provide multiple ways to create related many records in a way that updates the relation in the parent object.
In your case, you can either find that problem and fix it, or simply force reload the items in the mailer you are working on. To complain about bad code as a "Rails Problem" is not useful. Bad code can be written in any language, using any framework.
To be honest, I have written code that requires a reload where certain functionality is invoked. I have a callback on deleting a related many that modifies a value in the parent. However, that code really should be refactored such that the children are not destroyed directly, but instead a method on the parent should destroy the child.
Jim
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 rubyonrails-talk+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/02c26932-264f-4d7d-9194-973f0ef1d1ca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment