Cough, may I observe that an Object Relational Mapper that backs to a non-relational database can hardly be called that? This looks more like an elaborate API to Mongo, the sort of thing a user of something like Mongo will always end up writing anyhow and it's good to distribute those and collaborate on them. You get the same thing around relational DBs in any decently-architected system, too, even when they don't turn into "ORM"s. Even just something for writing SQL in a less brain-dead manner can be helpful.
I'm not criticizing the work at all, just saying that calling it an ORM is actively misleading, and probably going to chase people away who, if they just look at the title, will probably assume something really bad about what the project is, when in fact it looks quite useful.
Yeah, I know the term "ORM" is misleading, but I think it most succinctly expresses what it is. I certainly know that the "R" part of ORM isn't right, so should I call it an Oject Mapper? An Object Data Mapper?
Yeah, I saw another library called on Object-Document mapper. I'm thinking I'm going to call it something like an Object-based interface to MongoDB. I don't really like the name "mapper" :)
Why having no schema in your ORM is a good thing? I can understand that having dynamic schema on your DB probably will enable you to quickly change columns, indexes and so forth. And I understand that having an object that you can plug whatever properties to it at run-time is convenient for programming too. But why you should have no schema for ORM? It seems to me that if you can enforce schema in ORM, you can add columns/indexes as fast as your DB supports too (i.e. change the schema deceleration in your code), and have fewer bugs. Just curious about the reasoning behind this, I cannot figure it out. (Disclaimer: I am not familiar with Python)
Well, it depends on your application requirements.
And, remember that MongoDB itself is schemaless, so any schema validation must happen at the application layer, and thus, is always going to be "soft". For example, just because you declare a field to be an Integer in your application layer, it doesn't mean it's actually going to be an integer when you read an object. (Especially if objects are coming in through other external data sources.)
One great use case for schema-less design would be a User object where you wanted to store arbitrary credentials and external profiles from sites like Facebook, Twitter, etc. If you were using an enforced Schema, then you have to re-create the schema from all the external sites you're using, and every time there's a change in any one of those sites you need to "upgrade" your database to include these new fields. It's really pain.
On a related note, if you like python and MongoDB you might like my MongoMagic library: https://github.com/redbeard0531/MongoMagic. It lets you write queries like this: db.users.find(M.age > 21). This produces standard Mongo query objects so works with any ODM, or none at all. With Minimongo you could do something like Posts.find( 10 < M.comments.votes < 100 ).
Yeah, I've seen libs like this, and because I'm using the MongoDB native JavaScript shell for a bunch of other random tasks, I wanted to keep my Python query syntax as close to pymongo and thus to the native JavaScript as possible. Thanks for the link, though.
Just looking for some feedback, useful ideas. I was unsatisfied with both MongoKit and MongoEngine, so I decided to write my own very lightweight ORM for MongoDB in Python. Let me know what you think.
I found plain pymongo a bit too bare. I was starting to write connection pooling better DBRef support, etc. and that's what morphed into this library...
I'm not criticizing the work at all, just saying that calling it an ORM is actively misleading, and probably going to chase people away who, if they just look at the title, will probably assume something really bad about what the project is, when in fact it looks quite useful.