some notes from a n00b learning Mongoid

_mongoid_n00b_notes.markdown

Custom Keys

1. I typed identity :my_attr => String instead of identity :type => String. It failed later with a strange nil error. Turns out I wanted to use key :my_attr method instead. Would have appreciated an error saying :type was missing from the hash.
2. 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:
   1. Don't let me change a value used in a key at the point where I set it.
   2. Let me change a value related to a key, but don't update the _id itself
   3. Remove the old doc and make a new one and maybe assist me with renaming any references.
3. I didn't expect parameterize_keys to default to true (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.

Field Declarations

1. 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.
2. :type => Array feels strange. Everything else takes a type of something. Why not :array => String or something like that.

Railtie

1. 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]
   

Embedded Docs

1. 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.

Upserts

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.

custom_identity.rb

# It seems like it should be easier than this to customize an identity

class Foo
  class Identity < < Mongoid::Identity
    def identify
      document.id = some(:custom_logic)
    end
  end

  include Mongoid::Document
  identity :type => String

  def identify
    # use our identity subclass instead.
    Identity.new(self).create
  end
end

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. ;)

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.