- 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 agree with much here... There are certain things in Mongoid which are legacy, and I want to remove (like the parameterize keys and composite key functionality). Field declarations can be optimized like you desire, And the upsert thing is huge to me... I feel Mongoid has catered too much to the AR crowd in favor of ease of transition and not truly stayed true to the MongoDB ways... Although in many ways it does more than any other framework in that it does atomic updates under the covers - but not apparent to the user... The Railtie thing has irritated me as well... I had to override the migrations task to get cucumber to work properly but it hosed the ability to have both AR and Mongoid play nice in the same app together... I am working on a solution, but so many things to take care of right now. One at a time, and if I forget something please gently remind me or open a Github issue. ;)