DataMapper

Comments and changes to this ticket

• 

  Bernerd Schaefer July 20th, 2008 @ 02:03 PM

  • → State changed from “new” to “hold”

  I'm not really sure what can be done about this. The error is because in a number of places in DM, we do things like:

  Hash.new { |h,k| h[k] = [] }

  It makes sense, I guess, that Marshal can't dump hashes created like that.

  I'm going to put this ticket on hold, while we think about how this can be worked around. It seems like we'd need to serialize the object selectively ignoring certain special hashes, opting to set them back up on load.

• 

  Sam Smoot July 20th, 2008 @ 02:17 PM

  • → State changed from “hold” to “open”

  We need to implement #_load and #_dump methods in Resource for this to work. (see: http://ruby-doc.org/core/classes...

  The problem is that a single model instance references most of DM. It's like trying to dump a Request object in Merb or something with equally complex composition.

  So the standard solution is the above custom serialization methods.

  How do we get started on this? Take a look at Collection/Model#load. 90% of the state setting you'll need to be aware of is probably in there.

  That said, I'm going to re-open this, but we have a number of other issues to resolve before this becomes a priority.

• 

  idris August 5th, 2008 @ 04:52 PM

  This should really be a top priority, guys. Anyone writing a scalable Merb app will need to use memcached (or something similar), and it is not compatible with Datamapper.

• 

  Dan Kubb August 5th, 2008 @ 07:02 PM

  @idris: I think what Sam's saying is that compared to the other issues in the bug tracker this is not as high priority. Sam's team performs a large majority of maintenance on DM, so there's a good chance bugs with failing specs and blockers will be given higher weight when deciding where to prioritize his team's time.

  Not to sound too much like an ass, but if its a really high priority to you I'd suggest digging in and supplying a failing spec. Bugs without failing specs (like this one) are generally given the least amount of weight, and with about 90 outstanding tickets (currently) its likely that at least 70 or 80 of them will get attention first.

  If you really want this fixed provide a failing spec along with a patch to dm-core that fixes the issue. Ask someone in #datamapper and it would be applied to dm-core almost immediately. Also we have a pretty open commit policy, so if you asked for commit rights after this you're pretty much guaranteed to have them granted.

  Truly high priority tasks tend to bubble up to the top because affected parties will be motivated enough to remove the obstacles for the (relatively) small team of maintainers to deal with.