(I apologize in advance for top posting, but trying to keep this thread
consistent.)
I would say it's a definite problem for us. This project is an old legacy
project that several people have been working on for 6+ years. When I'm
rewriting, say, the receipt page and mailer, how could I possibly know in
advance that @order.line_items would give stale results without digging
through the details of the controller? If I have to do
@order.line_items(true) (and with every other has_many, etc.) everywhere
just to be sure, I'd rather just simply like to have the feature turned off
globally.
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
>
> On Monday, August 18, 2014 12:29:06 AM UTC-4, Phil wrote:
>>
>>
>> Thanks for the reply. It still seems to be a systemic integrity problem.
>> But the additional info on another work around is welcome.
>>
>>
>> Phil
>>
>>
>> On Sunday, August 17, 2014 9:17:10 PM UTC-7, tamouse wrote:
>>>
>>>
>>>
>>>
>>> On Sun, Aug 17, 2014 at 8:57 PM, Phil <ph...@edgedesign.us> wrote:
>>>
>>>>
>>>> I hate to reply to myself, but I narrowed it down to Rails caching by
>>>> DEFAULT of model queries. It can be worked around by passing 'true', like
>>>> this:
>>>>
>>>>
>>>> tc.name = "something different"
>>>>
>>>> tc.save!
>>>>
>>>> tp.test_children.map {|x| x.name }.to_sentence # => "test1, test2,
>>>> test3, and test4" *WRONG*
>>>>
>>>> tp.test_children(true).map {|x| x.name }.to_sentence # => "test1,
>>>> test2, test3, and something different" *CORRECT*
>>>>
>>>>
>>>> Another workaround is to just stop using has_many and such in favor of
>>>> manual functions, a la:
>>>>
>>>> def test_children
>>>>
>>>> return TestChild.where(["test_parent_id = ?", self.id])
>>>>
>>>> end
>>>>
>>>>
>>>> Is there a way to turn this sort of caching off globally? (Other
>>>> caching is fine, I don't want to turn all caching off.)
>>>>
>>>>
>>>> BTW- It is a bit mind blowing that this is turned on by default.
>>>> Possible data corruption shouldn't ever be preferred by default over
>>>> (possible) speed gains. I'd still categorize this as a serious bug, at
>>>> least as a configuration default.
>>>>
>>>>
>>>
>>> Try tp.reload after you make a change in the collection the way you have
>>> been. If you had been building your children entries as:
>>>
>>> tp.children.create(name: "test1")
>>>
>>> tp would be fully cognizant of all it's children.
>>>
>>
--
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+unsubscr...@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/dcd9ac4b-27b1-4118-b83d-89ac1a30b505%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
