If you add ./subdirectory to your windows PATH environment variable it works and you can run anything in your current_dir/subdirectory.

The issue occurs when you have a unique index in mongodb but don’t have a ‘validates_uniqueness_of’ in your model. With this combination and two similar records, mongo will reject the new record, but it will still insert into elasticsearch giving you a record in elasticsearch that doesn’t exist in mongodb. This is potentially a nasty bug.

The quick fix is to make sure that any unique index in your database also includes the ‘validates_uniqueness_of’ validator in your model.

I updated a project from Rake 0.8.7 to 0.9.2 (now that it doesn’t gag on the older code) and was met with this new “error”

So as an example here is one of my old tasks without arguments. I’ve

desc "Persist the dataset"
task(:dataset, :needs => :environment) do |t, args|
end


And the fixed version.

desc "Persist the dataset"
task(:dataset, [] => [:environment]) do |t, args|
end


Now an example with arguments.


desc "Insert the RGD genes into the database"
task :rgd_gene, :filename, :needs => :environment do |t, args|
end


And the fixed version.

desc "Insert the RGD genes into the database"
task :rgd_gene, [:filename] => [:environment] do |t, args|
end


I’m not sure if you need to use the arrays, but it works and the examples do show that.

I decided to remove the pagination and show the user the first set of records available. It then dawned on me that once you had multiple people working on the same page, they would all see the same records. This isn’t very efficient when you have a lot of stuff to get done. On a side note, this same problem existed in the paginated version, but when you have a link to move to the next page, it doesn’t crop up as much)

So now I needed to figure out a way to determine who was seeing what records, make sure that someone else didn’t see those same records at the same time, and make sure that if nothing was done to the records, they would return to the general pool in a reasonable amount of time.

Enter Redis.

I like redis. I’ve used it on a few other projects and felt that it would be a good fit since it has some nice set manipulation commands and the ability to expire a key after a specified amount of time. I started thinking about how to remove records after the user processed them and such, but I ran into some issues with possible AJAX search lag and that some records I didn’t really care about might be removed from the general population. Also, what do you do if the user only wanted to update a subset of those records? By modifying the key, I’d need to reset the expiration timer.

After writing a bit of code, I figured out that if I deleted the current user’s key before I make a union of all the users records, I wouldn’t have to worry about orphan records and unmodified records. Every time the user saw a list of records, only the current visible set would be removed from the general population.

Here’s a quick overview of what the script does.
2. Add the current user id to the set of curator ids
3. Remove the key that holds the current user’s reserved records
4. Get all the curator ids
5. Generate keys for all the curator reserved records
6. Get the union of all of the reserved records

I have to make a special note here. Redis expects arguments in the form SUNION “key1″ “key2″ “key3″. When you have an array in ruby, generally it will look something like ["key1", "key2", "key3"] The * (splat) operator splits out the array into a group of keys that works for the Redis command.

7-10. Find the first 15 currently available records and store the ids in the current user’s set in Redis.
11. Add a five minute expiration to the current user’s key.

It was interesting to me after thinking about it for a while that the solution ended up being so simple.

Hopefully I’ll be able to do more updates.

Anyway, this was probably blatantly obvious to a lot of people, but I figured I’d clear it up…

Email sent to Dreamhost back in August.

I’m going to make a request for this for you. Please note, it’s a significant bump from what we have right now, Rack 1.1.0, so only our rails expert can make the call, and check to make sure it won’t break anything. She’s on vacation this week, but I’ll send her a follow up email, so she can get back with you on this as soon as she’s back.

This was the response I got from Dreamhost after waiting for two months for an answer. (After I had to ask “hey, what’s up?”)

Thanks for writing. We have to be careful with the upgrade as we have a high number of dependency packages that need to go through the upgrade. It’s scheduled and being worked on, and the current estimate for the full upgrade to 3.0.1 is within a month of two. I’ll get back to you again when there is an update, but feel free to contact me if you have any more questions.

*Link includes my referral code