Datamapper DataMapper → 1.1

Comments and changes to this ticket

• You flagged this item as spam.
  

  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.

• You flagged this item as spam.
  

  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.

• You flagged this item as spam.
  

  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 (dkubb) 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.

• 

  Dan Kubb (dkubb) November 30th, 2008 @ 12:42 PM

  • Assigned user changed from “Sam Smoot” to “Dirkjan Bussink”

  Dirkjan, I believe since you removed most of the instances of Hash.new with a proc that this won't be an issue any longer. Can you confirm it is fixed in sam/dm-core? If not then we should probably make sure it's fixed in dkubb/dm-core so that this can be closed when we merge it into the mainline.

• 

  Dirkjan Bussink November 30th, 2008 @ 01:01 PM

  • State changed from “open” to “resolved”

  There is only one occurrence left, in the in memory adapter. This should not cause any problem for serialization. I'm closing this for now, if people do still have issues with it, please let me know.

• 

  Dan Kubb (dkubb) November 30th, 2008 @ 01:38 PM

  Dirkjan, I believe I removed it from the InMemoryAdapter in dkubb/dm-core too, so it's all good now.

• You flagged this item as spam.
  

  ronin-22245 (at lighthouseapp) January 1st, 2009 @ 05:51 PM

  I reported this issue in July and it's still broken... Wow...

  data = Marshal.dump(Article.first) #=> TypeError: no marshal_dump is defined for class Thread

• 

  Dan Kubb (dkubb) January 2nd, 2009 @ 03:22 PM

  • Tag changed from “bug” to “bug, marshal”

  @pchm: I'm not really sure what you expected. I asked you to provide failing specs and you never did.

  I tried a simple model and it worked fine with Marshal. I believe Dirkjan attempted too, and traced it to usage of Hash.new with a Proc object, which have all been removed from dm-core.

  If you are still having problems then it must be something specific in your model that isn't present in the ones I and Dirkjan tested with.

  Without further information it's unreasonable to expect issues to be fixed, especially if we are having trouble reproducing your exact conditions. If you don't know how to use RSpec, then just write a stand-alone script like the following that reproduces the issue:

  http://gist.github.com/29902

• 

  Ken Robertson January 3rd, 2009 @ 11:58 AM

  I had posted this as #691 as well and had a quick script to reproduce it. It still happens on 0.9.8, though haven't tried edge at all.

  http://gist.github.com/31593

• 

  Dan Kubb (dkubb) January 4th, 2009 @ 02:53 AM

  Ken, thanks for the pointer to #691, and especially the script reproducing the problem. Thanks to that I was able to track down the problem rather quickly and have committed the following fix in sam/dm-core:

  http://github.com/sam/dm-core/co...

  I am marking this as resolved for now. Please install this version of dm-core, and respond if it doesn't resolve the issue for you, and I will reopen the ticket.

• You flagged this item as spam.
  

  Anderson November 18th, 2010 @ 02:04 AM

  • Milestone order changed from “0” to “0”

  Hi,

  I'm using DM 1.0.2 and this error still happening, below is the class that I'm trying to put in Memcached and then the error 'can't dump hash with default proc' is raised:
  
class TestDm

  include DataMapper::Resource

  property :id, Serial property :created_at, DateTime property :created_on, Date property :updated_at, DateTime property :updated_on, Date

  has n, :tests, :through => :testing has n, :testing

  end
  

  Any clue?

  Thanks!

• You flagged this item as spam.
  

  Anderson November 18th, 2010 @ 09:49 AM

  Hi again!!

  Just for append more information on how about this error is occurring to me.
  If I try to put a DM Model in the cache in the execution of :after_filter the error is raised in others case the error don't occur.

  Regards!

• You flagged this item as spam.
  

  Caleb November 18th, 2010 @ 08:40 PM

  The commit that fixed this issue, wasn't included when the repo was moved from https://github.com/sam/dm-core to https://github.com/datamapper/dm-core.

  The last gem that included it was 0.9.11.

  I've attached a set of monkey patches that work in my environment with DM 1.0.2.

  • dm-marshal_monkey_patches.zip 7.7 KB

• You flagged this item as spam.
  

  Anderson November 19th, 2010 @ 11:37 AM

  But the guys from DM are not interested in merge this patch in the main branch of DM?

• 

  Martin Gamsjaeger (snusnu) November 22nd, 2010 @ 01:25 PM

  • State changed from “resolved” to “unconfirmed”
  • Milestone set to “1.1”
  • Milestone order changed from “15809” to “0”

  We actually are, but we haven't yet had time to investigate more on our side (the bug is old and only recently came up again)! If someone could even make a proper patch out of the collected monkey patches, that would definitely speed things up too.

• 

  Martin Gamsjaeger (snusnu) November 22nd, 2010 @ 01:25 PM

  • Assigned user cleared.
• 

  Xavier Shay November 25th, 2010 @ 10:39 PM

  • Assigned user set to “Xavier Shay”

  I am investigating and putting together a proper patch

• 

  Xavier Shay November 25th, 2010 @ 11:06 PM

  • State changed from “unconfirmed” to “resolved”

  I was unable to replicate this problem. I tried two things:

  1) Applied the specs from the above commit to current dm-core, and they all passed (except for the resource_spec, didn't know where to put it).
  https://github.com/xaviershay/dm-core/tree/marshal_specs.

  2) Added Anderson's code above into a stand alone script, no breakage against 1.0.2 https://gist.github.com/716295

  Tried on 1.8.7 and 1.9. Marking this ticket resolved, to open again please provide a modification of my gist that displays the problem, your environment (platform, ruby version), and the error you receive.

  As an aside, note that any objects (not just dm objects) marshaled under ruby 1.8 will cause errors if demarshaled on 1.9 - they are not compatible.

• You flagged this item as spam.
  

  Lance Ball January 11th, 2012 @ 01:18 PM

  Hi Xavier

  I was able to recreate this problem by making a simple change to your gist. Instead of requiring 'dm-core' and friends, I just require 'data_mapper' (is that no longer valid?). I get this:

  $ jruby spec.rb ~ (0.000000) PRAGMA table_info("test_dms") ~ (0.000000) PRAGMA table_info("testings") ~ (0.000001) PRAGMA table_info("tests") ~ (0.000000) SELECT sqlite_version(*) ~ (0.000002) DROP TABLE IF EXISTS "test_dms" ~ (0.000001) CREATE TABLE "test_dms" ("id" INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, "created_at" TIMESTAMP, "created_on" DATE, "updated_at" TIMESTAMP, "updated_on" DATE) ~ (0.000001) DROP TABLE IF EXISTS "testings" ~ (0.000002) CREATE TABLE "testings" ("test_dm_id" INTEGER NOT NULL, "test_id" INTEGER NOT NULL, PRIMARY KEY("test_dm_id", "test_id")) ~ (0.000001) CREATE INDEX "index_testings_test_dm" ON "testings" ("test_dm_id") ~ (0.000001) CREATE INDEX "index_testings_test" ON "testings" ("test_id") ~ (0.000001) DROP TABLE IF EXISTS "tests" ~ (0.000001) CREATE TABLE "tests" ("id" INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT) ~ (0.000001) INSERT INTO "tests" DEFAULT VALUES ~ (0.000002) INSERT INTO "tests" DEFAULT VALUES TypeError: can't dump hash with default proc
  

  dump at org/jruby/RubyMarshal.java:101
  

  (root) at spec.rb:40

  Note, this is using sqlite3 and jruby instead of postgres and ruby. I haven't confirmed on postgres and ruby mri because I don't have postgres installed at the moment, and ruby mri has an issue finding symbols with recent versions of dm-sqlite-adapter.

• 

  Piotr Solnica (solnic) January 11th, 2012 @ 01:28 PM

  @Lance we no longer use LH - all issues have been ported to github

• You flagged this item as spam.
  

  Lance Ball January 11th, 2012 @ 01:33 PM

  @solnic :) thanks