Datamapper DataMapper → 1.1.1

Comments and changes to this ticket

• 

  Martin Gamsjaeger (snusnu) July 12th, 2009 @ 02:12 PM

  • State changed from “new” to “not-applicable”
  • Milestone set to “0.10.0”

  Hmm, while the :content property is definitely stored inside the elements table because that's how STI does its thing, I do think that it's correct that the Element model (baseclass) does not understand it since it's actually declared in Textbug model (subclass). At least that's how I understand inheritance.

  Also, the error message explicitly states that there is no such property :content in the Element model, which is true, it's only in the Textbug model

  I'm marking this as not applicable.

  For reference, I stripped your script to the minimum (basically I removed the indirection through the additional method since it's not necessary to show the behavior) and ran it with latest next branch. The error message is better than the one you got with 0.9.11 and imho it's how it should behave.

  require 'rubygems'
  require 'dm-core'
  require 'dm-validations'
  
  class Element
    include DataMapper::Resource
  
    property :id, Serial
    property :type, Discriminator
  end
  
  class Textbug < Element
    property :content, Text
    validates_present :content
  end
  
  DataMapper.setup(:default, "sqlite3:///#{Dir.pwd}/content.db")
  DataMapper.auto_upgrade!
  
  box = Textbug.create({:content => 'hello'})
  Element.all.each do |e|
    puts e.content
  end
  
  # mungo:snippets snusnu$ ruby 911.rb 
  # /opt/local/lib/ruby/gems/1.8/gems/dm-core-0.10.0/lib/dm-core/query.rb:741:in `assert_valid_fields': +options[:field]+ entry :content does not map to a property in Element (ArgumentError)
  #   from /opt/local/lib/ruby/gems/1.8/gems/dm-core-0.10.0/lib/dm-core/query.rb:732:in `each'
  #   from /opt/local/lib/ruby/gems/1.8/gems/dm-core-0.10.0/lib/dm-core/query.rb:732:in `assert_valid_fields'
  #   from /opt/local/lib/ruby/gems/1.8/gems/dm-core-0.10.0/lib/dm-core/query.rb:708:in `assert_valid_options'
  #   from /opt/local/lib/ruby/gems/1.8/gems/dm-core-0.10.0/lib/dm-core/query.rb:706:in `each'
  #   from /opt/local/lib/ruby/gems/1.8/gems/dm-core-0.10.0/lib/dm-core/query.rb:706:in `assert_valid_options'
  #   from /opt/local/lib/ruby/gems/1.8/gems/dm-core-0.10.0/lib/dm-core/query.rb:648:in `initialize'
  #   from /opt/local/lib/ruby/gems/1.8/gems/dm-core-0.10.0/lib/dm-core/query.rb:354:in `update'
  #   from /opt/local/lib/ruby/gems/1.8/gems/dm-core-0.10.0/lib/dm-core/query.rb:370:in `merge'
  #   from /opt/local/lib/ruby/gems/1.8/gems/dm-core-0.10.0/lib/dm-core/collection.rb:73:in `reload'
  #   from /opt/local/lib/ruby/gems/1.8/gems/dm-core-0.10.0/lib/dm-core/resource.rb:817:in `reload_attributes'
  #   from /opt/local/lib/ruby/gems/1.8/gems/dm-core-0.10.0/lib/dm-core/resource.rb:802:in `lazy_load'
  #   from /opt/local/lib/ruby/gems/1.8/gems/dm-core-0.10.0/lib/dm-core/property.rb:660:in `send'
  #   from /opt/local/lib/ruby/gems/1.8/gems/dm-core-0.10.0/lib/dm-core/property.rb:660:in `lazy_load'
  #   from /opt/local/lib/ruby/gems/1.8/gems/dm-core-0.10.0/lib/dm-core/property.rb:539:in `get'
  #   from /opt/local/lib/ruby/gems/1.8/gems/dm-core-0.10.0/lib/dm-core/model/property.rb:206:in `content'
  #   from 911.rb:22
  #   from /opt/local/lib/ruby/gems/1.8/gems/extlib-0.9.13/lib/extlib/lazy_array.rb:458:in `each'
  #   from /opt/local/lib/ruby/gems/1.8/gems/extlib-0.9.13/lib/extlib/lazy_array.rb:458:in `each'
  #   from 911.rb:21
  

• 

  Martin Gamsjaeger (snusnu) July 12th, 2009 @ 02:21 PM

  • Assigned user set to “Dan Kubb (dkubb)”
  • State changed from “not-applicable” to “confirmed”

  Hehe, I don't quite understand why I missed the point that you explicitly created a Textbug instance :)

  So actually I do think that this is wrong behavior. When looping through all Elements I would expect the elements to be loaded with the actual type they have. Since you only added a Textbug resource, I think this code should not fail.

  Sorry for the confusion!

• 

  Dan Kubb (dkubb) July 22nd, 2009 @ 03:57 PM

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

  Dan Kubb (dkubb) October 4th, 2009 @ 09:33 PM

  • Milestone changed from “0.10.0” to “0.10.2”

  [project:id#20609 not-tagged:"0.10.0" milestone:id#51895 bulk edit command]

• 

  Dan Kubb (dkubb) October 6th, 2009 @ 01:08 PM

  Attached is a script to reproduce the problem.

  • ticket-911.rb 428 Bytes
• 

  Dan Kubb (dkubb) February 1st, 2010 @ 04:33 PM

  • Milestone changed from “0.10.2” to “1.0.0”

  [bulk edit]

• 

  Dan Kubb (dkubb) February 2nd, 2010 @ 02:34 AM

  • Assigned user cleared.

  [bulk edit]

• 

  Dan Kubb (dkubb) February 2nd, 2010 @ 02:45 AM

  • Milestone cleared.

  [bulk edit]

• 

  Dan Kubb (dkubb) February 2nd, 2010 @ 02:47 AM

  • State changed from “accepted” to “confirmed”

  [bulk edit]

• 

  Martin Gamsjaeger (snusnu) January 14th, 2011 @ 08:44 PM

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

  While I can't confirm the original failure, it seems as if lazy properties (like in this case the content property being of type Text) are not loaded correctly. I somehow think that there's a related ticket for that already. Once I found it, I'll add a cross reference.

  ree-1.8.7-2010.02@datamapper mungo:dm-core snusnu$ ruby 911.rb
   ~ (0.000103) SELECT sqlite_version(*)
   ~ (0.000134) DROP TABLE IF EXISTS "elements"
   ~ (0.000015) PRAGMA table_info("elements")
   ~ (0.000309) CREATE TABLE "elements" ("id" INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, "type" VARCHAR NOT NULL, "content" TEXT)
   ~ (0.000079) DROP TABLE IF EXISTS "elements"
   ~ (0.000007) PRAGMA table_info("elements")
   ~ (0.000107) CREATE TABLE "elements" ("id" INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, "type" VARCHAR NOT NULL, "content" TEXT)
   ~ (0.000054) INSERT INTO "elements" ("type", "content") VALUES ('Textbug', 'hello')
   ~ (0.000042) SELECT "id", "type" FROM "elements" WHERE "type" IN ('Element', 'Textbug') ORDER BY "id"
   ~ (0.000035) SELECT "id", "type" FROM "elements" WHERE "type" IN ('Element', 'Textbug') ORDER BY "id"
  nil
  

• 

  Dan Kubb (dkubb) March 16th, 2011 @ 10:41 PM

  • Milestone changed from “1.1” to “1.1.1”
  • Milestone order changed from “15” to “0”

  [bulk edit]