light_mongo: a lightweight MongoDB object persistence layer for Ruby
LightMongo is a lightweight Mongo object persistence layer for Ruby which makes use of Mongo’s features rather than trying to emulate ActiveRecord. It’s an interesting alternative to the already popular and somewhat awesome MongoMapper.
Comments
Does the existence of a lib/core_ext/* directory in any lib fire alarm bells with anyone else?
It’s good the author avoids the urge to use ActiveSupport (or whatever does this stuff in Rails) as a dependency for something so trivial but polluting Ruby’s namespace with #blank? methods for 2 (by my count) calls in persistence.rb still rubs me the wrong way.
It’s all personal preference I guess but if you must alter the way Ruby behaves outside your library why not at least mixin a module rather than re-opening so I can guess which module is responsible for the pollution and either patch the code or remove the dependency.
Shanna, good point. Post an issue on the github issues page and I’ll scope its usage to the library’s internals.
Yet another reinvention of the wheel? I seriously don’t get it. And it’s not gonna stay “lite” if the author thinks about features like lazy loading queries, dirty attributes etc.
Good to see I am not the only one to point out these things around here. Solnic is totally on track with his comment. Of course now he will be labeled a troll.
As long as it doesn’t require ActiveSupport it already has a leg up on MongoMapper.
If people didn’t reinvent the wheel, we wouldn’t have Nginx, Ruby, Nokogiri, or a whole ton of useful stuff. Alternatives keep things alive.
First of all, I love MongoMapper. I use it. It has everything I need. However, I can also see it from the author’s perspective that you don’t need all of it all the time. Why use Sinatra for example? Rails has most everything you need. Let everyone’s ideas flow. If it’s good, people will use.
It’s good to have alternatives. I’m a big fun of alternative solutions. For instance I prefer Merb over Rails, DataMapper over ActiveRecord, Linux over OSX, Progress Rock over Pop etc. :) My point was that in this special case of MongoDB ORM there’s no need to reinvent the wheel. Especially there’s no need to start writing something that’s supposed to be lightweight because it’s impossible to support MongoDB features and keep the ORM lightweight.
Regarding “why do you need sinatra if you have rails”…it’s a bad example. Why? Because you need sinatra if you’re building a small web app. You don’t need MongoDB if you’re building something small, you need sqlite3. See my point?
ps. lol, I guess I am a troll right now :)
And oh, ActiveSupport is now cherrypickable so I don’t think it’s wrong to use some of its libraries. Most of the ORMs will be using ActiveSupport soon. Just deal with it :)
“ActiveSupport is now cherrypickable so I don’t think it’s wrong to use some of its libraries”
@solnic This is very OT but if AS is multiple libraries then it should be multiple gems so dependencies are clear without having to dig through source code. The mantra is “Do one thing well”.
For example I’m personally not a fan of polluting Ruby with ‘core extensions’ at the library level especially when it happens through indirect dependencies. It would be nice to know up front when a gems dependencies are resolved so I can choose to avoid, patch or fork the library.
These are really basic instructions but still important. Really it’s very useful and informative. Its good tips and easy steps. So thanks for オンラインカジノnice post.
One more ruby object persistence solution for mongodb https://github.com/alexeypetrushin/mongo_db
One more ruby object persistence solution for mongodb https://github.com/alexeypetrushin/mongodb https://github.com/alexeypetrushin/mongodb_model
Post a comment