Datamapper DataMapper

Comments and changes to this ticket

• 

  Dan Kubb (dkubb) December 2nd, 2008 @ 04:56 AM

  • State changed from “new” to “open”
  • Assigned user cleared.

  Perhaps we should convert the second argument to DataMapper.setup to a Mash when it is a Hash so that the keys can be either String or Symbol objects.

  In fact, a little more broadly, we should think about ensuring that is the case elsewhere in the DM API. Anyplace that accepts a Hash where the keys are Symbols should convert it to a Mash so that the keys may also be String objects.

• 

  Dan Kubb (dkubb) January 8th, 2009 @ 04:47 AM

  • State changed from “open” to “confirmed”
• 

  Dan Kubb (dkubb) January 8th, 2009 @ 03:01 PM

  • State changed from “confirmed” to “not-applicable”

  Nwallins: I've thought about this, and I think in the case of DataMapper.setup we'll continue to make it so that it accepts a Hash of Symbol objects. While there are public facing parts of DM that need special consideration for String/Symbol keys, I don't think this is one of them.
  

  DataMapper.setup is almost never used directly by end users, and when it is we provide a URI based API, and a Hash w/Symbol key API, I wouldn't want to confuse matters by providing a third option. Since there is usually a layer in front of DataMapper.setup, I think it's reasonable to assume that the user-facing layer will perform whatever normalization is necessary on the user supplied data.

  What I'd rather see is merb_datamapper parse the YAML, and then send DataMapper.setup a Mash object. This is preferable to converting to a Mash internally, and should work fine inside DM.

  merb_datamapper is maintained by the merb team, and a ticket can be created here:

  http://merb.lighthouseapp.com/pr...