[Rails-core] Adding provider attributes to ActiveJob
Hello, Looking into ActiveJob a bit, it seems similar to carrying along the provider's Job ID ( https://github.com/rails/rails/issues/18821 ), providers should be able to include additional meta data about the job; things that would not be appropriate as arguments because they're related to the job itself and are handled / generated by the provider. My current use case is using Shoryuken, I would like to access some of the meta data about the job (i.e. when was it first queued). It seems like a fairly straightforward addition, I am willing to put together a PR, but I'm interested to see if there was a conscious decision to not include it. Thanks, Bob Bob Breznak | 617 863 0262 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
Re: [Rails-core] ActiveRecord connection pool management
On Monday, 5 October 2015 14:37:56 UTC+11, Michael Vigilante wrote: > This is also an excellent point; I wasn't aware this was the case. It > certainly feels like a waste to be doing this every time a database > operation is run. I'm not sure what an appropriate level of alive-checking > is; I'll see if I can find out how other systems do this. > OK; looks like other systems either do an alive-check on each checkout (I don't *think* this necessarily needs to run a query on the database; for example, JDBC provides a `connection#isAlive` method; I can't find any source for what this actually *does* though. Maybe it does just run a query), or they do it scheduled in a background thread, which probably isn't an option here because of the GIL. My guess is that because my tests were run with the database so close to the app (on the same machine), this wasn't really an issue; I guess latency would be the real performance-killer in this case. I'll rerun the tests with an external database just to be sure. The other issue I noticed (which I just realised I hadn't mentioned) was that I had to disable the query cache middleware in order to make checking in and out connections possible; I'm not entirely sure what that middleware is for (it appears to just semi-temporarily enable the query cache on all requests?), but it poses a problem to checkin-checkout (even in the manual sense). -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
