Time Based Queries are Caching Undesirably

[Jay Sanders]

I posted this question on Stack Overflow, but thought some of your awesome local developers might be able to help me. The Stack Overflow thread is here: http://stackoverflow.com/questions/14755643/time-based-queries-are-caching-undesirably

I am working on a Rails 3.2 application. We are running on Ruby 1.9.3 and Postgres 9.1.3. Most of the content on the site is organized by a published_at datetime stamp. The public facing queries ask for content in relation to the Time.zone.now:

Post.where(["published_at <= ?", Time.zone.now]).order("published_at DESC")

When I go into the console and run this query, I get exactly the posts that I expect. However, the application controller in production seems to be caching and is not bringing in new content that may be relevant based on it's published_at timestamp.

I realize I can disable caching using 'config.action_controller.perform_caching' in the production environment config file, but this seems like very bad form as I will be caching view content in the future.

Is there something I am missing to make the Controller actually make legitimate database calls regularly? Is this a Rails issue or a Postgres configuration issue?

Thanks!

[Mark Locklear]

Is this running on a local or hosted server? I am just wondering if Time.zone.now could be messing users up. Won't Time.zone.now always be the same...EST if its local. Wouldn't you want that be set based on where the user is at (not the server). Just thinking outloud..

--
You received this message because you are subscribed to the Google Groups "Asheville Ruby Users Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to asheville-rb...@googlegroups.com.
To post to this group, send email to ashevi...@googlegroups.com.
Visit this group at http://groups.google.com/group/asheville-rb?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
J. Mark Locklear
-Philippians 4:13 gives you the muscle, but YOU have to flex it!

"One machine can do the work of fifty ordinary persons. No machine can do the work of one extraordinary individual."
-- Elbert Hubbard

[Jay Sanders]

Mark,

Thanks for the thoughts.  Time.zone.now is actually correct.  The site administrators are based in New York and therefore would like all of the content to revolve around the Eastern Time Zone.  ActiveSupport::TimeZone is actually a great feature of Rails that eliminates any confusion when translating dates to and from the database.

Excellent blog post on the subject: http://www.elabs.se/blog/36-working-with-time-zones-in-ruby-on-rails

ActiveSupport::TimeZone in the API documentation: http://api.rubyonrails.org/classes/ActiveSupport/TimeZone.html

Jay Sanders
http://creativeallies.com
http://enormustrio.com

http://acousticsyndicate.com

“To practice any art, no matter how well or badly, is a way to make your soul grow. So do it.” ~ Kurt Vonnegut, A Man Without a Country

[Jay Sanders]

I have done some more testing and experiments. In my specs, all of the content querying is happening as expected. I set "config.action_controller.perform_caching" to false in production and turned off memcached. The queries are still not responding in real time. Does anyone think this could be a postgres issue? 

Jay Sanders
http://creativeallies.com
http://enormustrio.com

http://acousticsyndicate.com

“To practice any art, no matter how well or badly, is a way to make your soul grow. So do it.” ~ Kurt Vonnegut, A Man Without a Country

[Phillip Miller]

Jay, I've never used this, but a quick google search tells me there's a clear_cache! instance method on the AbstractAdaptor module. You might throw that after your initial call as a hack-n-code solution. But yeah, I'm guessing its in the adapter or db level, it does some magic caching of queries for sure. 

http://rubydoc.info/docs/rails/ActiveRecord/ConnectionAdapters/AbstractAdapter#clear_cache%21-instance_method

Just curious, was your console test on dev or production? I'm guessing production, but if not, you could try it there. 

[Andy Vanasse]

Jay: Seems like config.action_controller.perform_caching is related to template/partial caching (view layer) but your problem is related to DB caching.  Perhaps the wrong config option?

[Andy Vanasse]

...and it looks like the (class-level) uncached method may do the trick.

Post.uncached{ Post.where(["published_at <= ?", Time.zone.now]).order("published_at DESC") }

[Jay Sanders]

Andy,

Thanks!!  That's quite a find with uncached I'll insert that into the code and see what happens. 

I was definitely concerned about config.action_controller.perform_caching because this project is going to scale very quickly and I will need to install view caching to meet the request demands.

Jay Sanders
http://creativeallies.com
http://enormustrio.com

http://acousticsyndicate.com

“To practice any art, no matter how well or badly, is a way to make your soul grow. So do it.” ~ Kurt Vonnegut, A Man Without a Country

[Fuzz Leonard]

Assuming uncached works is that the right way to go? It seems that you would want the caching enabled but to flush it after saving a Post. Assuming folks will be viewing Posts more often than publishing them, of course :)


:Fuzz

[Jonathan Greenberg]

Hey Jay,

 "There are only two hard problems in Computer Science:
   cache invalidation and naming things."

   -- Phil Karlton

Time zone issues also always makes my head hurt.

This may be obvious but have you configured your Rails app in production (config.time_zone = 'Eastern Time (US & Canada)') as well as your server to use EST? This probably would not be the issue if you were testing the console on the actual production server.

A failing integration spec might be a great tool for getting this resolved if you can create one.

Jonathan Greenberg

p.s. I would enjoy pairing on this with you if you find yourself burning too many hours without resolution.