Repository navigation
uninitialized constant Moped::BSON::Binary #46
Description
Running into this on Rails 4.1.4, Mongoid 4.0.0, Carrierwave 0.10.0, carrierwave-mongoid 0.7.1 and Mongoid-grid_fs 2.1.0 4dbecf1.
When uploading files via Carrierwave into GridFS, it's blowing up in lib/mongoid/grid_fs.rb in the "binary_for" method on line 172:
def binary_for(*buf)
if defined?(Moped::BSON)
Moped::BSON::Binary.new(:generic, buf.join)
else
BSON::Binary.new(buf.join, :generic)
end
endThe problem seems to be that Moped::BSON is still defined somewhere in the project, so it's using the old Moped BSON class even though that's been phased out. Actually, I found that if I change it to
if defined?(Moped::BSON::Binary)it works just fine, but I'm not exactly sure what the consequences of that are (I honestly don't know what the Moped::BSON constant is defined at all).
I'll fork and submit a pull request, and let you guys decide. Thanks.
Activity
mu-is-too-short commentedon Jan 9, 2015
Did you ever get any resolution on this? I just hit the same problem while trying to upgrade a Rails3 app to Rails4. My current plan is to fork my own copy and beat some sense into it.
rmm5t commentedon Jan 9, 2015
Mongoid, Moped, and BSON have had a strange history with one another. At one time, Moped did not depend on the bson gem for it's BSON handling. That's why there's the
Moped::BSONcheck.Moped::BSONshould have completely gone away, so please see if you can find out whereMoped::BSONis still being defined.mu-is-too-short commentedon Jan 9, 2015
@rmm5t Thanks. I think I've found some stray
Moped::BSONthings in my code that are confusing mongoid-grid_fs'sdefined?calls. I love upgrading, it is the best time ever! Heh.dblock commentedon Oct 18, 2026
The concrete legacy BSON-class checks from #48 are carried forward in #88, with a fresh-process regression for a Moped::BSON namespace without Binary. Keeping this issue open until the fix merges.
Posted by an AI on behalf of @dblock.