Here's a little lib I wrote that implements support for after_commit
callbacks:
http://gist.github.com/76868
On Mon, Mar 9, 2009 at 2:43 PM, Alex MacCaw wrote:
>
> Yes, I'm still getting the error.
>
> On Mar 9, 2:39 pm, Jan De Poorter wrote:
> > As far as I can se
Yes, I'm still getting the error.
On Mar 9, 2:39 pm, Jan De Poorter wrote:
> As far as I can see observers after_save calls are still in the
> transaction.
>
> regards,
> Jan De Poorterhttp://workswithruby.com
>
> On 07 Mar 2009, at 18:31, Alex MacCaw wrote
Thanks for the suggestion, will do.
On Mar 7, 4:43 pm, Pratik wrote:
> On Sat, Mar 7, 2009 at 4:40 PM, Eloy Duran wrote:
> > So maybe a patch to add the after_commit API, as used in the article,
> > would be a good idea.
>
> Or if possible, just use observers.
> --
> Cheers!
> - Pratikhttp://m.
us state.
>
> So maybe a patch to add the after_commit API, as used in the article,
> would be a good idea.
>
> Eloy
>
> On 7 mrt 2009, at 15:34, Alex MacCaw wrote:
>
>
>
> > I've got a message queue running, and record ids get added to it in an
> > a
I've got a message queue running, and record ids get added to it in an
after_create callback.
However, the message queue is so fast that it can't find the records.
This is because the record hasn't actually been saved back to the
database yet - after_create is called in the transaction.
There's
Just wanted to run this by a few people to get some feedback.
At the moment, fragment cache (as indeed Rails.cache) calls often look
a bit like this:
<% cache("[EMAIL PROTECTED]") do %>
I was thinking cache should take multiple arguments, which would be
joined with an underscore, like this:
<% c
I'm just wondering about the switch from mongrel to thin as the
default server.
I'm not sure it's such a good one, considering that the --debugger
option doesn't work for example.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Goo