-
Notifications
You must be signed in to change notification settings - Fork 156
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
better Rails integration #134
Conversation
@@ -1,4 +1,6 @@ | |||
task :environment | |||
task :environment do | |||
ActiveRecord::Base if defined?(Rails) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is necessary because I can't initialize the connection in the Railtie. (This would force Active Record to be loaded and a connection to be made when booting Rails). I'm not sure this is the best alternative though.
@ryandotsmith no I did not consider the linked issue while implementing. It was more a proof of concept to see if you are interested in more automatic integration with rails. As mentioned in one of my comments, passing the connection is not optimal at the moment. |
@senny I see. I am excited to see the queue_classic setup become easier for rails developers. 👍 |
good. I'll think about a good way to pass the connection so that we don't need to load AR prematurely and we don't have the issues described in #96. |
👍 |
I'm looking forward to this PR. It will help with a problem I've run into when my specs end up calling QC.enqueue: there's no DATABASE_URL and it raises an exception. I currently set DATABASE_URL using a Further, I propose there be an option to put QC into a dummy mode so that when it gets asked to make a job, it merely confirms that it could but doesn't hit the database. I'm almost accomplishing this now through mocking, but it would be nice to be global. E.g. I have:
I would prefer to be able to leave the mock out of my specs and let QC infer it from the enqueue call. I can think of two "testing" modes that people might want.
For the former, I figure something along these lines in spec helper: # untested
QC.stub(:enqueue) do |method, *args|
eval method + " #{args}"
end |
@turadg I don't think we need to provide specific testing behavior. QC is tiny, focused and modular. It should be easiy to just adapt it to your testing needs. In my applications I always used custom Skimming through the code I did not see a code to set the default_queue I think the |
@senny any easier way to mock QC would be much appreciated. Can you post here or in the wiki an example of how you're mocking the queue now? |
I always use wrapper code around I then simply use different queues to verify different behavior. Sometimes to just store the jobs in an array to see if they were added, sometimes I wrap a real queue to do some introspection before. The I can't post the samples as they are properties of my clients but I think I'll write something up when I implement |
@senny I see. The default queue setter will definitely help. Thanks! |
@ryandotsmith I removed the simplified connection handling from this PR to get it merged. I will take a look at #167 to see how we can integrate more easily with AR. |
I finally had the time to work on a "smoother" Rails integration. This PR adds:
Using queue_classic with Rails is now as simple as adding the gem and running
rails g queue_classic:install
.I tested using a fresh rails 3.2.13.rc2 app.