In Ruby, there are currently 3 ODM (object data mappers) maintained:
MongoMapper
Mongoid
MongoDoc
Which is your preferred and why?
I just chose Mongoid for a new Rails 3 project based on the argument that it has the best documentation.
Since I am new to MongoDB (with many years of MySQL and a little bit of CouchDB experience), I needed good guides that take me by the hand and help me deliver something working within a reasonable span of time.
AFAIK Mongoid has just that: a nice looking site, with well documented guides for newbies like me.
Code Stats for Mongoid and MongoMapper
It looks like MongoMapper has much better code quality (if it does the same with less).
Here's the analyzer CodeStats https://github.com/alexeypetrushin/code_stats
In my opinion it's hard to say which is better, if you have DataMapper experience you'll like MongoMapper, but if you used ActiveRecord, Mongoid it's your preferred choice. I believe all of them worths a try concerning the context where you want to use them.
I am using MongoMapper. It good except it is little slow with Time conversions.
And it loads all data as Array. MyCollection.all for example gives you huge array, not cursor.
while Mongoid says: - Optimized for use with extremely large datasets.
So I guess you could try MongoID if you need speed and have big recordsets.
I was trying MongoMapper, but I think I'll go with Mongoid, because after quick reading docs it seems to me somewhat easier. Plus, it's developed by guys from Hashrocket, so that's a good reason itself.
While not a direct answer to your question, I would also consider using the basic ruby driver directly. Unlike the various SQL adapters out there Mongo's ruby class is easy to use and powerful. Because queries are hashes, composing queries is generally easy. The real advantage is access to the Atomic Modifiers. If you benefit from a Document database, these modifiers should be in your toolbox.
Having said this, I will go ahead and recommend MongoMapper because it has cleaner integration with the non-CRUD parts of MongoDB. Both projects are making gains in this area, and the situation may have changes since I did my research in December 2010.
I can recommend MongoMapper, since it also works with rails3 (beta and master). I personally didn't try the other 2 mappers you mentioned, since MM works great in my workflow and the mailinglist is very active. Furthermore the codebase is really stable and the only issue is with rails3 master, so you should use fredwu's branch, which already includes fixes for the current rails3 master changes on form_for: http://github.com/fredwu/mongomapper.git
There's also MongodbModel http://alexeypetrushin.github.com/mongodb_model
Related
I'm developing a Gem which I think will be useful for more people than just me. One issue I'm facing is that I need to merge nested hashes. I found this useful Gist to accomplish that, but now I'm wondering if it's okay to modify Hash# like this in a Gem?
I'm sure there's a community "standard" or best practices that either accepts or declines this sort of code, so I'm turning to SO for guidance.
Thank you.
When in doubt, just subclass Hash and include the Module in your subclass. You should particularly do this, when you override methods or change the behavior dramatically.
But i don't see why you shouldn't just modify the Hash class. Rails, for example, extends Core classes rigorously and i've never heard someone complain. You might take a look at how Rails' activesupport extends core classes:
https://github.com/rails/rails/tree/master/activesupport/lib/active_support/core_ext
Just make sure not to break existing behavior, so the users of your gem will not experience unwanted side-effects.
You should always have a good reason for extending core class. I'd say that deep merging is good enough reason. To add new Hash method for deep merging like Hash#deep_merge - why not.
But I don't believe it justifies modifying existing method - overriding Hash#merge to support deep merge. People expect this method to behave certain way and if it suddenly behaves differently after requiring your gem, they won't like it. If you absolutely must do it, describe it at the prominent place in your documentation.
UPDATE: just read the comments under the other answer. Yeah, best solution in this case is simply to include activesupport/lib/active_support/core_ext/hash/deep_merge :)
Usually to remove some fields from collections in MongoDB, $unset is used. What can I do in Ruby to accomplish that? I have tried to read this, but I couldn't understand how to use it. I am new to Ruby and still learning to work with it.
The $unset operator is used through the update command which is documented here for the ruby driver.
Taking a step back, the standard (10gen-maintained) MongoDB Ruby driver can do absolutely everything that mongodb can. It exposes very literally the full capabilities of mongodb, just like the mongodb drivers in other languages do. So don't worry about being able to do mongo things in any particular language.
You might be wondering about the capabilities of popular ODM layers since they vary. ODM layers map mongodb documents to native language objects. In Ruby, mongoid is the most popular ODM. As #Tilo points out, it also supports explicitly removing fields from documents through its higher-level API.
Please check this issue for Mongoid:
https://github.com/mongoid/mongoid/pull/635
p = Product.first
p.raw_attributes.delete :foo
p.save
I cannot seem to find any Object Databases for Ruby (do not confuse with Document Oriented, like Coach and Mongo).
Do more or less mature OODBMSs for Ruby exist?
Thanks.
I don't know much about it, but I believe that the MagLev implementation of Ruby will include an object database.
There aren't any mature ones — because it isn't typically done or desired by Rubyists.
I need a good reference for how to use standard Libraries in Ruby. Current libraries do not describe or give examples like say Java's. Yet this is where examples are much more needed (in Ruby), because I am not familiar with what the called method will yield! I am left with having to look at the source files every time, which seems inefficient. What is a good standard library reference... or am I just not understanding blocks yet?
I find myself bouncing around between the ruby core API on ruby-doc.org, googling for answers on random blogs, and spending time testing ideas in the interactive interpreter (irb). I haven't seen any other core reference documentation that I liked, but I do have a copy of The Ruby Way and its pretty decent.
Betweeen these four sources I can almost always find out how to solve the problem I'm working on.
Best of luck - ruby is fun, frustrating, and powerful.
There is the Ruby Standard Library documentation and sites like apidock. The Pickaxe book has a great reference towards the end. There's even a free version online, but it's quite out of date; to find the reference there, click Standard Library in the top-left frame.
Try GotAPI You'll be able to find the Ruby standard documentation and a whole lot of api docs there
Understanding blocks is pretty important, especially if you want to understand the Enumerable module. ruby-doc.org is usually all I need, but if I need a little more explanation I grab the PickAxe. You need the PickAxe, no question.
I am sorry , but again, i have to recommend ruby cookbook. (Already two times today)
How easy would it be to write a dumb LINQ provider that can just use my class definitions (which don't have any object references as properties) and give me the translated SQL. It can assume the name of the properties and the columns to be same as well as the names of the classes and the underlying tables. Can you please give me some pointers.?
It took me about 4 months of fulltime work (8 hours a day) to build a stable, working provider that implements the entire spec of linq. I would say I had a very simple, buggy and unstable version after about three weeks, so if you're just looking for something rough I would say you're probably looking at anything from a week up to two months depending on how good you are and what types of requiements you have.
I must point you to the Wayward blog for this, Matt has written a really good walkthrough on how to implement a linq provider, and even if you're probably not going to be able to copy and paste, it will help you to get to grips with how to think when working. You can find Matt´s walkthrough here: http://blogs.msdn.com/mattwar/archive/2007/07/30/linq-building-an-iqueryable-provider-part-i.aspx . I recommend you go about it the same way Matt does, and extend the expression tree visitor Matt includes in the second part of his tutorial.
Also, when I began working with this, I had so much help from the expression tree visualizer, it really made parsing a whole lot easier once you could see how linq parsed to queries.
Building a provider is really a lot of fun, even if a bit frustrating at times. I wish you all the best of luck!
Give a look to the LINQExtender project, is a toolkit for creating custom LINQ providers.
Another option for giving you a leg up seems to be re-linq which is a framework for creating custom LINQ providers.
Here's the Source code and a nice overview (pdf) of what's involved in writing one.
I’ve written a tutorial series on my blog base on my experience developing a LINQ-to-SQL provider from scratch, starting with the expression tree composition stage (calling the LINQ methods), continuing with the expression visitor, breaking down of the query into components, parsing the where clause, generating the text and parameter and, eventually, compiling the whole thing into IL using the .NET expression namespace.
I’ve seen many incomplete posts that promised to explain how to write a provider, falling very short of the mark, barely scratching the surface and not actually delivering anything remotely executable.
The blog series I’ve written based on my experience has a sample project available for download with the simple provider that covers only the functionality required by the tutorial example. However, it also includes the production version supporting a number of operations (where, join, first, count, top, etc.), subqueries, nested statements, and etc. Additionally, it produces a cleaner SQL than a lot of what I’ve seen from Entities and LINQ-to-SQL. There’s no unnecessary/redundant nesting, wrapping everything in brackets and etc.
For anyone with a good level of abstract thinking, developing such a provider isn’t such a difficult task many set it out to be. I’ve developed one that’s used in production environment in about 3 months of part time work (meaning some evenings and weekends). From the get go it was aimed with performance and tidy SQL in mind – a goal it achieved.
It was a little hard to find the time to publish this material, but I thought – if it may help someone out there, there’s no reason for this experience to go to waste:
How to write a LINQ to SQL provider in C# Part 1 - Introduction
How to write a LINQ to SQL provider in C# Part 2 - Expression Visitor
How to write a LINQ to SQL provider in C# Part 3 - Where Clause Visitor
How to write a LINQ to SQL provider in C# Part 4 - Compiling Expression Trees
I have created a project 'LinqToAnything' which is designed to make it very very easy to implement a (simple) Linq provider.