Hello--
On Jul 15, 2009, at 9:40 AM, Jedrin wrote:
>
>
> I have a few questions.
>
> One is that it seems like script/runner does some caching because if
> you destroy a bunch of active record models using myrec.destroy, then
> if you do a find() of some sort, they are still there (even though you
> deleted them) until the instance of script runner that you are in
> exits. Then if you restart it, the find will not find it.
>
> Based on that, it seems that it might be better to have a long
> running process spawn script/runner jobs separately rather than have a
> script/runner that runs for a long time and does a ton of stuff, not
> sure on that ?
>
> I also noticed that backgroundrb logs to the same log as the web
> server. If a whole ton of stuff happens in backgroundrb, could this
> potentially slow down the web server because it uses the same log
> file ? The same question applies for script/runner. I see it happening
> more so because I run the server from the console while developing
> probably etc.
You might try
YourARModel.clear_query_cache
if you feel caching is to blame for returning stale (already deleted)
rows. However, I am skeptical that caching is the problem, as it
(AFAICT) caches the most recent query so you have to make a query
identical to the last one for it to kick in. Additionally, any
modification to the model such as creating, updating, or deleting
should invalidate that cache.
You might try to reproduce this in a simple test case and look at the
SQL in your logs to make sure you are seeing what you expect.