Sign in through GitHub

Please read for an updated status on RailsCasts:

Learn more or hide this

HuckyDucky's Profile

GitHub User: HuckyDucky

Comments by

Avatar

I'm going to attempt to answer my own question, it makes a little bit of sense after having written it down.

The Rails.cache.fetch call will attempt to return something for the key passed in, but it you also pass it a block it will execute the block and use the resulting value for that key if it wasn't already set.

And passing [article, "foo"] as the cache key is the same as passing:

articles/5-2013blahblahblahfoo

which is just a unique identifier in the cache. Slowly filtering through my dense head.

OK great. So a better example might have used something that would demonstrably change had the block been executed each time the fetch message was sent:

Rails.cache.fetch([user,'foo']) { Time.now }
=> 2013-05-13 23:59:40 -0400

wait 5 seconds, then:

Rails.cache.fetch([user,'foo']) { Time.now }
=> 2013-05-13 23:59:40 -0400

Now I get it. ;-)

Avatar

2:34 to 3:03. Those two sentences makes no sense to me whatsoever. I've listened to it 10 times, and I can't tell what that line does. Sometimes the "foobar" terminology is unhelpful.

"So, if we pass a model object to the fetch method it's going to automatically use the cache key for that object, and we can supply multiple keys in an array and they will be joined together. So let's say we have some kind of property we want to compute on that article, we can execute that in a block here and this block will be executed just once when it sets the key and the next time we trigger it it won't trigger the block because the key is already set unless we change the Article model and that will change the key value."

Here is the line Ryan is describing:

Rails.cache.fetch([article, "foo"]) { 123 }

which returns:

=> 123

then he types it in the console again, and the same thing happens. What does this line do again? And what does "123" do? And how do I know that it isn't triggered the second time?

How is any fetching done when nothing in the cache had been set yet? I am really missing something on this one.

Avatar

I was getting a "PG::Error connection closed" message. Here is the solution:

For Postgres users who are also using Spork, the Plataformatec blog solution will not work as stated. In other words, if you put the shared_db_connection.rb file in your spec/support directory, you will get a PG::Error connection closed message. Leave the file in spec/support but remove this line:

ActiveRecord::Base.shared_connection = ActiveRecord::Base.connection
And instead put that in your Spork.each_run block in your spec_helper.rb file.

H/T nicholasmott from the comments section on the Plataformatec blog.

Avatar

FactoryGirl fails with:

undefined method `error_field' for nil:NilClass

No stack trace given, naturally.

Avatar

This doesn't work for me. All "page.should have_content" assertions fail under this stack. And when I do a "save_and_open_page", well, there's no styling and no JS. In other words, there's nothing available from the asset pipeline. It has been a real struggle. 5 12-hour days straight trying to set up this testing stack. What a waste.

Avatar

I am so confused. What is the difference between this and Cucumber?