Recently, I needed to do some background processing. I just needed something simple, and looking at all various options, I decided to go with Bj. It was fairly simple to understand, and best of all, didn't require another daemon to be running by hand–it started one itself if you didn't configure it.
However, it's incompatible with SQLServer. I'm guessing no one's every used it with SQLServer before, since I didn't read anything about it in my research. Bj uses a column called "key" which SQLServer reserves as a future keyword, and thus, automatically changes the name of the column to "[key]" So consider yourself forewarned.
Thus, I decided to switch to something similarly simple, and I started using Delayed Jobs
. It's all fine, except in some instances, I ran into the following error:
LoadError: Expected /[RAILS_ROOT]/vendor/plugins/delayed_job/lib/delayed_job.rb to define DelayedJob
After reading around on the web for a while, it seemed like any number of things could cause this error. I finally found way down in this rails ticket
from a while back, had the lines that explained it.
The critical comment at that link is: "Prior to this revision, Rails would happily load files from Ruby’s standard lib via const_missing; you will now need to explicitly require such files."
The rest of the comments also talked about various causes. It's the case of different problems having the same symptom, and here, the backtrace isn't pointing to where the problem is.
In the case of Delayed Job, Rails expects delayed_job.rb to define a module or class named DelayedJob. However, that plugin doesn't have any such class or module. It defined Delayed::Job instead. So when loading up dependencies, It's looking for DelayedJob module or class when there is none.
A workaround is to simply define an empty DelayedJob module in your config/environment.rb file, or feel free to put it in a file under config/initializers if you don't want to pollute your environments file. Hopefully, that saves you some pain. tip.