- I typed
identity :my_attr => String
instead ofidentity :type => String
. It failed later with a strange nil error. Turns out I wanted to usekey :my_attr
method instead. Would have appreciated an error saying :type was missing from the hash. - If you change a value related to the key, it fails silently. It even says it saved succesfully when it didn't. I would have found any of the the following behaviors reasonable as long as they were documented:
- Don't let me change a value used in a key at the point where I set it.
- Let me change a value related to a key, but don't update the _id itself
- Remove the old doc and make a new one and maybe assist me with renaming any references.
- I didn't expect
parameterize_keys
to default totrue
(or that it even exists) and it took me reading thru the code to understand what was going on. I had a field that was safe in a url but it turned my dashes into "-dash-" for no apparant reason. Once I understood it, I found that I couldn't provide a function that composed my key -- it had to be a field.
- Why can't I specify several fields in one line if they share common options? Sure I can make a loop, but that does seem like it should be necessary.
:type => Array
feels strange. Everything else takes a type of something. Why not:array => String
or something like that.
-
As a project migrating from active record, I found that I couldn't generate db migrations anymore (needed to make a new column to store the document id in sql for synchronization). This seems antithetical to mongoids philosophy of opt-in for the behaviors you want. The error I got was this:
$ rails g migration add_mongo_id_to_resources error mongoid [not found]
- I wanted a simple embedded doc that existed for the purpose of helper methods and validations, not for saving on an individual basis, but I still have to have an _id
attribute on each. This seems strange because it means I can't convert a simple nested hash into an object(or can I?) and it uses more space than I really need it to. I would like to be able to say
key :disabled => true
or something like that.
While building a sql <=> mongo synchonizer, I discovered that upsert didn't really work with the same semantics of mongo's upsert instead it was based on the ruby object's state. I expected to be able to create a new document and do an upsert and it would either create or update. I found that it would create but that subsequent updates did not take unless I did a find on the document _id first and operated on the document object that was returned. This is a lot like active record, of course, but I find it antithetical to the mongodb approach. Making matters worse was the fact that mongoid failed silently -- saying that it had updated the document when it hadn't.
I spent too much time chasing down this weird ORM behavior with an embedded doc. Say, self is an embedded doc, and self.parent is the container doc, and x is a field of the emebed doc. This sequence: self.x = true; self.save; self.parent.save; would not save either doc, but would update the object references. I have to first get self.parent.select to get another instance of the same embedded doc from the parent, then save it.