Get a look fast – I have a feeling some of these might not exist at these URL’s for all that long (especially the PDF’s)
This one gave me fits for a little bit not too long ago, and crept up on the mongoid list the other day.
One of the greatest things about mongo in what it does is the idea of embedding documents into other documents – at times removing the need for relations where it makes sense. The classic example being Blog posts and comments within that post. Why not just shove the comments directly inside of the blog posts’ documents? It’s faster and makes sense – these are just documents right? So let’s treat them as such.
But on occasion the need for relations remains. On a toy app I’ve begun rewriting to use Rails3 and Mongo (Mongoid, specifically) I ran into a conceptual road-block that I’ve seen creep up on occasion between the other (relative) newbies like myself – how the relations are stored between Mongoid objects. I needed a relational association instead of just embedding (why? the size limit for collections probably would have bitten me in the ass in the future). But after following the conventions in the documentation and inspecting how things ended up in the database I realized I had a few things twisted.
I think part of it, at least for me, is the idea of embedding gets in the way of how you perceive this getting stored within the mongo document(s). Take the example at the mongoid documentation under “Relational Associations”
class Person
include Mongoid::Document
references_many :prescriptions
end
class Prescription
include Mongoid::Document
referenced_in :person
end
When I look at that – I think that the Person would collect the references to Prescription, perhaps in a :prescriptions array. Such is not the case. Instead the Prescription objects contain a single reference to its “parent” object – Person. Below is a comparison of what you might think, versus how it’s actually stored in the database
john = Person.create
prescription = Prescription.create
john.prescriptions << prescription
john.save
How you might perceive this is being stored
# john =>
# {
# "_id" : ObjectId("4cc2f0bac0b37e9c17000001"),
# "_type" : "Person",
# "prescriptions" : [ ObjectId("4cc2f0bac0b37e9c17000002") ]
# "created_at" : "Sat Oct 23 2010 10:27:06 GMT-0400 (EDT)"
# }
# prescription =>
# {
# "_id" : ObjectId("4cc2f0bac0b37e9c17000002"),
# "_type" : "Prescription",
# "created_at" : "Sat Oct 23 2010 10:27:06 GMT-0400 (EDT)"
# }
Versus what this is actually doing
# john =>
# {
# "_id" : ObjectId("4cc2f0bac0b37e9c17000001"),
# "_type" : "Person",
# "created_at" : "Sat Oct 23 2010 10:27:06 GMT-0400 (EDT)"
# }
#
# prescription =>
# {
# "_id" : ObjectId("4cc2f0bac0b37e9c17000002"),
# "_type" : "Prescription",
# "created_at" : "Sat Oct 23 2010 10:27:06 GMT-0400 (EDT)",
# "person_id" : ObjectId("4cc2f0bac0b37e9c17000001")
# }
I realize this follows the same old ActiveRecord conventions of the parent ID being stored in the children objects, but when you develop that big ole’ crush on, and get married to, the idea of mongo’s embedded documents – it’s difficult to switch gears!
If any information is misrepresented or factually incorrect please leave a comment and let me know!
After quite a bit of digging around, and a little help from mr. Jose Valim at Plataformatec, I realized that the combination of the Devise authentication gem, along with Rack-Tidy, aren’t quite so friendly with each other. The main culprit here, I would say is the Tidy gem. Why? Because the essence of its existence is to re-arrange the markup handed back from the app-server. So some things get lost in the shuffle during all that house-cleaning (please, correct me if I’m wrong).
I had a hunch that with a little musical chairs in the middleware stack, we could find a solution that would allow all pieces to live harmoniously. Luckily, I was right. The trick is to make sure Tidy is inserted into the stack before ActionDispatch::Flash (because Rack::Tidy was killing the flash messages returned from Devise/Warden) and before Warden::Manager (the rack authentication layer beneath Devise). The resulting stack, for me, looks like so (important bits in bold):
use ActionDispatch::Static
use Rack::Lock
use ActiveSupport::Cache::Strategy::LocalCache
use Rack::Runtime
use Rails::Rack::Logger
use ActionDispatch::ShowExceptions
use ActionDispatch::RemoteIp
use Rack::Sendfile
use ActionDispatch::Callbacks
use ActionDispatch::Cookies
use ActionDispatch::Session::CookieStore
use ActionDispatch::ParamsParser
use Rack::MethodOverride
use ActionDispatch::Head
use ActionDispatch::BestStandardsSupport
use Rack::Tidy
use ActionDispatch::Flash
use Warden::Manager
use Sass::Plugin::Rack
run MyApp::Application.routes
And is accomplished with this code instead the app initialization process (application.rb):
config.middleware.delete ActionDispatch::Flash # remove from current position
config.middleware.insert_before Warden::Manager, ActionDispatch::Flash # add it right back in before Warden
config.middleware.insert_before ActionDispatch::Flash, Rack::Tidy, 'indent-spaces' => 2 # finally, add in Rack:Tidy before ActionDispatch::Flash.
The resulting stack looks like it’s working quite well for now.