datamapper/dm-core

DataMapper - Core

dm-core's Issues

dm sometimes generates an order by clause that postgres doesn't accept

an example of the query being generated is:

http://pastie.org/1684418

discussed with dkubb on irc who requested I add this ticket.

---

Created by Matt - 2011-03-17 23:30:53 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/1495

has 1 doesn't respect :defaults for existing resources

If you have a Model (which has a number of existing resources) that you add a new has 1 relationship to, defaults for that relationship will not be respected.

class Parent
  include DataMapper::Resource
  property :id, Serial

  has 1, :child, :default => proc { Child.new }
end

class Child
  include DataMapper::Resource
  belongs_to :parent, :key => true
end

If the models are as shown, then:

 @existing_parent = Parent.first
 @existing_parent.child
#=> nil

 @new_parent      = Parent.new
 @new_parent.child
#=> #<Child ...>

See the attached ticket for a script to demonstrate the problem.

---

Created by Jonathan Stott (namelessjon) - 2010-07-04 14:27:19 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/1351

Json type / Hash assignment fails to mark attribute as dirty.

After changing the Hash, Resource#save returns true without a DB update.

See attached test.

---

Created by ojak - 2009-10-19 10:31:53 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/1098

Overwriting default_scope conditions is broken

require 'rubygems'
require 'dm-core'
require 'spec'

DataMapper::Logger.new(STDOUT, :debug)
DataMapper.setup :default, "sqlite3::memory:"

class User
  include DataMapper::Resource

  property :id,     Serial
  property :active, Boolean

  default_scope(:default).update(:active => true)

  auto_migrate!
end

describe "Overwriting default scope conditions" do
  before :all do
    @active   = User.create(:active => true)
    @inactive = User.create(:active => false)
  end

  it "should overwrite a condition" do
    users = User.all(:active => false)

    users.size.should == 1
    users.first.should == @inactive
  end
end

The produced query looks like this:

SELECT "id", "active" FROM "users" WHERE ("active" = 'f' AND "active" = 't') ORDER BY "id"

---

Created by Piotr Solnica (solnic) - 2010-02-24 12:30:04 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/1202

duplicate association names should be rejected

If I define two different associations having the same name, DataMapper should warn and/or reject the model.

---

Created by Clifford Heath - 2010-09-23 07:03:10 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/1417

Complex filtering should not require explicit field values for matching

Quick example:

Task.all(Task.taggings.tag.id => tag.id)

works, but

Task.all(Task.taggings.tag => tag)

throws an ArgumentError. The above two queries should work identically.

Provide additional options to relationship getters

Here's a sample use case where this would be invaluable -- being able to specify fields to load on a belongs_to relationship to avoid eager loading data we don't need.

    posts = Post.all

    posts.size # => 842
    posts.user.count # => 840

    posts.each do |post|
      puts "#{post.title}, by #{post.user.name}"
      # This will eager load all user data for all
      #840 users:
      #   select * from users where user_id in (...)
    end

    # proposal:

    posts.each do |post|
      user = post.user(:fields => :name)
      puts "#{post.title}, by #{user.name}"
      # This will eager load only name (and id) for the users:
      #   select id, name from users where user_id in (...)
    end

---

Created by Bernerd Schaefer - 2011-01-19 11:55:00 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/1479

add new AR compatibility methods?

Pretty simple, and might help with ppl switching between methods:

module DataMapper
  module Model
    def table_name(v) storage_names[:default] = v.to_s end

    #AR-style scoping of queries - any others needed?
    def limit(z) all(:limit => z) end
    def order(z) all(:order => [z]) end
    def where(z) all(:conditions => z) end
  end
end

Created by Kevin Watt - 2010-06-27 19:51:17 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/1342

SEL not carried through for associations

Not sure if this is a bug or a new feature.

According to http://datamapper.org/articles/spotlight_on_laziness.html, SEL supposed to avoid the n+1 query problem. It references Zoo.find(:all, :include => [ :animals ]).each {}. find is no longer in the current 1.0.0 api, so one can only assume that DM is taking care of this under the hood.

I found a case (http://pastie.org/1119328) where each iteration of
Device.all(:limit => 100, :offset => k).each {|i| r << i.x} triggers a separate join request for each association. This loop took close to 3 seconds to perform. When the associations were removed [with all data defined in the same Device table] the same loop took only 68ms.

So, yes, n+1 is a performance killer in some cases. Per Dan Kubb's suggestion, I got around this by creating a view of the associations and define a model on top of this view. It would be nice to have DM handle this automatically.

---

Created by thomas - 2010-08-28 23:53:34 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/1396

support for timezone in DateTime or Time

currently (dm-core v1.0.2) does not consider the timezone
property created_at, DateTime
makes this field (in postgresql)
created_at | timestamp without time zone |

---

would it be possible to specify:
property created_at, DateTime, :timezone => true
to make the field (in postgresql)
created_at | timestamp with time zone |

i'm assuming that other databases could have correct behavior under the proposed semantics, i only know this with postgresql

this would simplify date times for the cases where an absolute time is needed but serialization and parsing need to be in an arbitrary time zone.

---

Created by flazz - 2010-09-30 13:33:01 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/1422

error when :through is used with a chained method

This issue is best understood by looking at a simple bit of code:

:through seems to make this raise, but it only raises when there is a chained method added, see this example:

https://gist.github.com/3f56de49b1002f1b5442

---

Created by Matt - 2010-06-28 20:44:53 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/1343

Union across associations resets foreign keys

Given the following models:

    class Activity
      belongs_to :post, required: false
      belongs_to :user, required: false
    end

    class Post
      belongs_to :user
      has n, :activities
    end

    class User
      has n, :posts
      has n, :activities

      def all_activities
        activities | posts.activities
      end
    end

When User#all_activities is called, the foreign keys of post activities are re-bound to the User model:

    user = User.create
    user.activities.create

    post = Post.create(user: user)
    post.activities.create

    user_activity, post_activity = user.all_activities

    assert_equal user.id, user_activity.user_id
    assert_equal nil, user_activity.post_id

    assert_equal post.id, post_activity.post_id
    assert_equal nil, post_activity.user_id
    # FAIL:
    #   <nil> expected but was <1>
    #   post_activity.dirty_attributes # => {:user_id => 1}

Full test case here: https://gist.github.com/773035

---

Created by Bernerd Schaefer - 2011-01-10 17:15:28 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/1472

No foreign key after auto_upgrade!

With the two models.

class Person
  include DataMapper::Resource

  # Primary Key
  property :id, Integer, :key => true

  # References
  has n, :loans, "Ticket", :child_key => [:loaner_id], :constraint => :protect
  has n, :debts, "Ticket", :child_key => [:loanee_id], :constraint => :protect
end

class Ticket
  include DataMapper::Resource

  # Primary Key
  property :id, Serial

  # General Properties
  property :loan_id, UUID, :required => true, :default => lambda { |r, p| UUIDTools::UUID.random_create }, :unique_index => :loan_index
  property :loaner_id, Integer, :required => true, :unique_index => :loan_index
  property :debt_id, UUID, :required => true, :default => lambda { |r, p| UUIDTools::UUID.random_create }, :unique_index => :debt_index
  property :loanee_id, Integer, :required => true, :unique_index => :debt_index
  property :amount, Decimal, :scale => 2, :required => true
  property :started_on, Date, :required => true
  property :expired_on, Date
  property :description, String, :length => 140, :lazy => true
  property :status, Enum[:pending, :active, :cancelled, :closed], :default => :pending, :required => true

  # References
  belongs_to :loaner, "Person"
  belongs_to :loanee, "Person"

  # Validations
  validates_with_block { loaner != loanee }
  validates_with_block(:if => :expired_on) { started_on <= expired_on }
end

auto_upgrade! create no foreign key in database. ( see attachment).

---

Created by Siegfried Levin - 2011-03-02 05:24:36 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/1493

DataMapper::Repository#read with an invalid query returns an ambiguous result

If you ask a Repository to read the records for a valid query which returns an empty set, you get an empty set.
If you ask a Repository to read the records for an invalid query, you get an empty set.

It is impossible to determine the difference between these results.

Can we change the behaviour for an invalid query to raise an error?

https://github.com/datamapper/dm-core/blob/master/lib/dm-core/repository.rb#L160-163

ManyToOne::Relationship#get is much slower in DM 1.0.2 v.s. DM 0.10.0

In DM 1.0.2, ManyToOne::Relationship#get takes 3.4 seconds per 515 calls. DM 0.10.0 takes 0.11 seconds per 400 calls.
This slows down validation that happens when an object is created.

It goes down to Query#initialize that is around 4 times slower in DM 1.0.

---

Created by Alexander Sorokin - 2010-11-02 21:23:26 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/1442

[PATCH] Add Extlib::ByteArray as a core primitive type

I need to be able to read and write binary (bytea) fields using a Postgres database. Attached is a patch that adds Extlib::ByteArray as a primitive type. DataObjects takes care of everything else.

---

Created by Peter Brant - 2009-10-02 02:36:24 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/1071

dm-core/support/inflector is gone in Edge

My code tries to detect/load the available Inflector library. I was depending on dm-core/support/inflector.rb being available, but it appears the file was removed in dm-core edge. Could this file be re-added before the next release? Once a file is added and released, it's probably a good idea to not remove it, until a major version.

Support for UTC/GMT timestamps

For a project we are currently working on, it is important that the date/times stored in the database are in UTC/GMT (timezone offset of +00:00).

Activerecord has a configuration option to enable this:

ActiveRecord::Base.default_timezone = :utc

DataMapper unfortunately has not (as far as we can tell). For now, we have changed the TIMESTAMP_PROPERTIES constant in dm-timestamps.rb to the following:

datetime = DateTime.now.new_offset(0)
date = Date.parse( datetime.to_s )
TIMESTAMP_PROPERTIES = {
  :updated_at => [ DateTime, lambda { |r, p| datetime                                    } ],
  :updated_on => [ Date,     lambda { |r, p| date                                        } ],
  :created_at => [ DateTime, lambda { |r, p| r.created_at || (datetime if r.new_record?) } ],
  :created_on => [ Date,     lambda { |r, p| r.created_on || (date     if r.new_record?) } ],
}.freeze

This fixes the issue for now. However, it would be nice to make this option configurable. Does anyone share our opinion on this matter?

If so, we could create a patch. The one thing we are not sure about is how to set such a configuration option. Any ideas?

---

Created by Bright 4 - 2009-05-27 09:36:19 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/868

Creating a resource with relationships is 3 times slower on DM 1.0 v.s. DM 0.10

Persisting 100 instances of a resource on DM 1.0 takes 4.76 sec (with profiling on). The same operation takes 1.16 seconds on DM 0.10. Screenshots are attached. The model has around 20 properties and 4 related resources (it belongs to them).

Profiling screenshots are attached.

---

Created by Alexander Sorokin - 2011-03-17 04:07:17 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/1443

STI + Text on child + each bug

Hey again

Having more STI problems. This time, it's accessing a text property only on a child object.

This is as far down as I can get the bug:
http://pastie.org/517114

The error only happens when text is defined on the subclass, and I access the text value through a separate method inside of an each call.

Gem versions are 0.9.11 - let me know if there's any more info needed.

Thanks!

david

---

Created by David Kelso - 2009-06-18 23:58:48 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/911

Save returns false after assigning existing value to a lazy Text property

Given a model with lazy Text property, if an instance of the model is loaded (but with the Text property not loaded because of laziness), if you assign to the property the value already stored in the db, attempting to save the object will return false.

If there is one or more lazy Text properties in the model, assigning to any of them a value other than the original value will cause save to return true.

I have only tested/observed this issue with MySQL.

---

Created by MarkMT - 2009-10-22 16:21:37 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/1102

Setting Integer belongs_to property to empty string should not fail property validation

Scenario:

• Model defines an optional belongs_to relationship
• User submits form with <option value="" name="user_id"></option>

Expected behavior:

• user_id is cleared

Actual behavior:

• user_id is set to "", which results in a "User must be an integer" error

The following patch solved this problem for me (typecasting blank to nil for Integer fields): https://gist.github.com/769304

---

Created by Bernerd Schaefer - 2011-01-07 10:00:49 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/1470

DM doesn't handle sub-selects properly.

---

Created by Dan Sully - 2010-06-18 06:20:23 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/1330

Multiple problems with :limit / :offset

I noticed that :limit and :offset are not handled correctly when chaining together different queries.

Combining :limit with last

#last appears to just reverse the order of the query, instead of properly calculating the index of the last row in the query. This is partly due to the fact MySQL applies ORDER BY before applying OFFSET or LIMIT.

HugeModel.all(:offset => 100, :limit => 100).last.id
# SELECT `id`, `created_at` FROM `huge_models` ORDER BY `id` DESC LIMIT 1 OFFSET 100
# => 1168824

I would expect #last to add limit - 1 to the value of :offset.

Combining :offset with Array access

When accessing queries like an Array, it does not respect :limit or :offset.

HugeModel.all(:offset => 100, :limit => 100)[50].id
# SELECT `id`, `created_at` FROM `urls` ORDER BY `id` LIMIT 1 OFFSET 50
# => 51

I would expect #[] to add the current :offset to the index key.

Also #[] should respect the :limit option and not allow indexing outside of the Collection bounds:

HugeModel.all(:offset => 100, :limit => 100)[10000].id
# SELECT `id`, `created_at` FROM `urls` ORDER BY `id` LIMIT 1 OFFSET 10000
# => 10001

Querying with string condition keys causes explosions when keys collide with class methods

So for instance if i have a property called :name on a model (say Foo), and i try to query with Foo.all("name.like" => "%taco%"), the query will exploooode because Foo.name calls the classmethod and does not return the appropriate property.

Likewise if you define any other class methods which overload a property, the same behavior takes place.

I have attached a simple patch which addresses this specific issue below.

---

Created by Ted Han (knowtheory) - 2010-10-12 20:59:34 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/1433

Stack level too deep when collecting relations

While trying to jsonify a collection of objects and include their relations I've stumbled across what I assume is a bug. I've boiled it down to a test case and it seems to be something more fundamental than serialisation.

Test case and a couple of specs are attached. The stack trace looks like:

stack level too deep
/Library/Ruby/Gems/1.8/gems/dm-core-1.0.2/lib/dm-core/resource.rb:635:in `collection'
/Library/Ruby/Gems/1.8/gems/dm-core-1.0.2/lib/dm-core/collection.rb:510:in `each'
/Library/Ruby/Gems/1.8/gems/dm-core-1.0.2/lib/dm-core/support/lazy_array.rb:413:in `each'
/Library/Ruby/Gems/1.8/gems/dm-core-1.0.2/lib/dm-core/support/lazy_array.rb:413:in `each'
/Library/Ruby/Gems/1.8/gems/dm-core-1.0.2/lib/dm-core/collection.rb:508:in `each'
/Library/Ruby/Gems/1.8/gems/dm-core-1.0.2/lib/dm-core/query/conditions/comparison.rb:616:in `map'
/Library/Ruby/Gems/1.8/gems/dm-core-1.0.2/lib/dm-core/query/conditions/comparison.rb:616:in `expected'
/Library/Ruby/Gems/1.8/gems/dm-core-1.0.2/lib/dm-core/query/conditions/comparison.rb:461:in `matches?'
/Library/Ruby/Gems/1.8/gems/dm-core-1.0.2/lib/dm-core/query/conditions/operation.rb:461:in `matches?'
/Library/Ruby/Gems/1.8/gems/dm-core-1.0.2/lib/dm-core/query/conditions/operation.rb:159:in `each'
/Library/Ruby/Gems/1.8/gems/dm-core-1.0.2/lib/dm-core/query/conditions/operation.rb:159:in `each'
/Library/Ruby/Gems/1.8/gems/dm-core-1.0.2/lib/dm-core/query/conditions/operation.rb:461:in `all?'
/Library/Ruby/Gems/1.8/gems/dm-core-1.0.2/lib/dm-core/query/conditions/operation.rb:461:in `matches?'
/Library/Ruby/Gems/1.8/gems/dm-core-1.0.2/lib/dm-core/resource.rb:635:in `collection'

---

Created by Mike Stenhouse - 2010-10-12 11:26:59 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/1431

Useless exception message when trying to save invalid model

Consider this database model:

require 'dm-core'
require 'dm-migrations'

  class Foo
    include DataMapper::Resource
    property :id, Serial
    property :foo, String, :required => true
  end


DataMapper.setup( :default, "sqlite:///tmp/sqlite.db" )
DataMapper.auto_migrate!
DataMapper::Model.raise_on_save_failure = true
Foo.create!

/usr/lib/ruby/gems/1.9.1/gems/dm-core-1.1.0/lib/dm-core/resource.rb:1197:in `assert_save_successful': Foo#save! returned false, Foo was not saved (DataMapper::SaveFailureError)
    from /usr/lib/ruby/gems/1.9.1/gems/dm-core-1.1.0/lib/dm-core/resource.rb:420:in `save!'
    from /usr/lib/ruby/gems/1.9.1/gems/dm-core-1.1.0/lib/dm-core/model.rb:704:in `_create'
    from /usr/lib/ruby/gems/1.9.1/gems/dm-core-1.1.0/lib/dm-core/model.rb:463:in `create!'
    from databasemodel.rb:14:in `<main>'

Pretty useless exception message. Should be something like "Missing value for :foo property".

Has many IN query gives wrong results

Entry.all( :tags => Tag.first ).size should equal Entry.all.select {|e| e.tags.include? Tag.first }.size

A complete example to illustrate the issue can be found at: https://gist.github.com/bdc83b7c7f8797517f03

---

Created by Robert Sköld - 2010-04-30 23:38:26 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/1259

Datamapper freezes gtk

I'm using datamapper for persistence in this (http://github.com/Bolthar/rubydraulica/tree/master) application. The starts up smoothly then, after a couple of minutes after Datamapper.setup is been called, the ui freezes and the process' cpu % goes up to 100% (or 50% in dual core systems, 25% on quad). That means that the widgets don't get updated anymore, if i try to resize the window it doesn't get repainted, i can't focus on anything, the only fix is to kill the process and start it over again.
This actually happens only under unix, i've tried the same configuration (ruby 1.8.6, ruby-gnome 0.16) under both windows XP and ubuntu linux 9.04 and under windows everything works fine.

---

Created by Andrea Dallera - 2009-07-10 18:54:03 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/966

Cannot destroy records

I have a model set up like the following:

class Task
  include DataMapper::Resource

  property :id, Serial
  property :name, String, :length => 1..128

  property :completed, Boolean, :default => false
  property :difficulty, Integer, :default => 5
  property :deadline, DateTime

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

  belongs_to :project

  has n, :taggings
end

When I call Task.destroy or Task.first.destroy, the response code is false and there is no error returned. What's going on? I want to delete them!

Chaining class finder methods generating incorrect query

class NewModel
  include DataMapper::Resource

  property :id ,Serial
  property :use_starts_at, DateTime
  property :use_ends_at, DateTime

  def self.usable_after(time)
    all(:use_starts_at => nil) | all(:use_starts_at.lt => time)
  end

  def self.usable_before(time)
    all(:use_ends_at => nil) | all(:use_ends_at.gt => time)
  end
end

NewModel.auto_upgrade!
NewModel.usable_after(Time.now).usable_before(Time.now)

# Expected SQL: 
# SELECT `id`, `use_starts_at`, `use_ends_at` 
# FROM `new_models` 
# WHERE 
# (`use_ends_at` IS NULL OR `use_ends_at` > '2010-07-06 15:42:18')
# AND
# (`use_starts_at` IS NULL OR `use_starts_at` < '2010-06-05 15:42:18')
#
# Generated SQL:
# SELECT `id`, `use_starts_at`, `use_ends_at` 
# FROM `new_models` 
# WHERE (`use_starts_at` IS NULL OR `use_starts_at` < '2010-07-06 15:42:18')

---

Created by bcrouse - 2010-07-06 23:24:23 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/1354

Querying via a HABTM relationship broken

Perhaps this syntax simply isn't supported - but if not, I would expect an error, not an incorrect result:

Using MySQL, and with a structure like this:

class Business
  has n, :categories, :through => Resource
end

class Category
  has n, :businesses, :through => Resource
end

I would expect the following to return all businesses in category 1:

Business.all(:categories => {:id => 1})

But instead, it returns all businesses with :id => 1. I don't know if this is specific to MySQL, or a general bug.

The first SQL statement it issues selects category.id from categories JOIN business_categories JOIN businesses where category.id = 1 (selecting category.id where category.id = 1 is kinda useless... right? It just returns '1' a few times)

---

Created by mltsy - 2011-04-20 16:25:52 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/1505

Incorrect table name in join

This issue was discussed here, back in January: http://irclogger.com/datamapper/2010-01-14#1263459912. Short summary: joins are screwed up when joining to more than one table.

I can't find a ticket for it and it's still a problem in master. The problem is described here: http://gist.github.com/276940.

The target_alias for the join should be based on relationship instead of previous source_alias. I have patched the problem here: http://github.com/alexkwolfe/dm-do-adapter/commit/cbc97c39da6e1ee4d548dedb231d3532d6a151e6.

---

Created by Alex - 2010-04-18 19:57:10 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/1249

[PATCH] rails_datamapper get it to run with rails 2.3.0

rails_datamapper gave me a few problems:

• Rails.root always gives an empty string
• DataMapper.rake did not load the model files for automigrate/autoupgrade
• the model generator did not generate my properties

the attached patch solves these little problems

---

Created by kristian - 2009-02-22 17:12:26 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/804

destroy problem when child_key explicit declared.

in relationships with the child_key explicit declared, the destroy returns false

example:
has 1, :friendship, :child_key => [ :source_id ]

multiple query paths map to the first child model.

I noticed when using multiple query paths with a model that had multiple belongs_to relationships, the other query paths would map to the first child model.

gem 'dm-core', '~> 1.0.2'
gem 'dm-migrations', '~> 1.0.2'

require 'dm-core'
require 'dm-migrations'

class HostName

  include DataMapper::Resource
  include DataMapper::Migrations

  property :id, Serial

  property :name, String

  has 0..n, :urls

end

class Port

  include DataMapper::Resource
  include DataMapper::Migrations

  property :id, Serial

  property :number, Integer

  has 0..n, :urls

end

class Url

  include DataMapper::Resource
  include DataMapper::Migrations

  property :id, Serial

  belongs_to :host_name

  belongs_to :port

  property :path, String

end

DataMapper.setup(:default, 'sqlite3:dm_bug.db')
DataMapper.auto_migrate!

url = Url.create(
  :host_name => {:name => 'example.com'},
  :port => {:number => 80},
  :path => '/index.html'
)

# works
puts (
  Url.all('host_name.name' => 'example.com') &
  Url.all('port.number' => 80)
).first


# fails
puts Url.first(
  'host_name.name' => 'example.com',
  'port.number' => 80
)

#<Url:0x00000001c522d0>
/home/hal/.rvm/gems/ruby-1.9.2-p136/gems/dm-do-adapter-1.0.2/lib/dm-do-adapter/adapter.rb:142:in `execute_reader': no such column: host_names.port_id (DataObjects::SyntaxError)
    from /home/hal/.rvm/gems/ruby-1.9.2-p136/gems/dm-do-adapter-1.0.2/lib/dm-do-adapter/adapter.rb:142:in `block in read'
    from /home/hal/.rvm/gems/ruby-1.9.2-p136/gems/dm-do-adapter-1.0.2/lib/dm-do-adapter/adapter.rb:260:in `with_connection'
    from /home/hal/.rvm/gems/ruby-1.9.2-p136/gems/dm-do-adapter-1.0.2/lib/dm-do-adapter/adapter.rb:138:in `read'
    from /home/hal/.rvm/gems/ruby-1.9.2-p136/gems/dm-core-1.0.2/lib/dm-core/repository.rb:162:in `read'
    from /home/hal/.rvm/gems/ruby-1.9.2-p136/gems/dm-core-1.0.2/lib/dm-core/model.rb:379:in `first'
    from dm_bug.rb:64:in `<main>'

---

Created by Postmodern - 2011-01-05 02:30:47 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/1467

find_by_sql in dm-ar-finders interacts badly with dm-aggregates count

If you do Thing.find_by_sql(blah).count then it gives you the results of Thing.all.count instead. Example script demonstrating this attached.

---

Created by DRMacIver - 2010-09-21 11:01:15 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/1416

slice seems broken on datamapper collections

[1,2,3][1..-1] = [2,3]
Foo.all[1..-1]

ArgumentError: +options[:limit]+ must be greater than or equal to 0, but was -1
from /Library/Ruby/Gems/1.8/gems/dm-core-1.0.2/lib/dm-core/query.rb:922:in assert_valid_limit' from /Library/Ruby/Gems/1.8/gems/dm-core-1.0.2/lib/dm-core/query.rb:773:inassert_valid_options'
from /Library/Ruby/Gems/1.8/gems/dm-core-1.0.2/lib/dm-core/query.rb:767:in each' from /Library/Ruby/Gems/1.8/gems/dm-core-1.0.2/lib/dm-core/query.rb:767:inassert_valid_options'
from /Library/Ruby/Gems/1.8/gems/dm-core-1.0.2/lib/dm-core/query.rb:363:in update' from /Library/Ruby/Gems/1.8/gems/dm-core-1.0.2/lib/dm-core/query.rb:596:inslice!'
from /Library/Ruby/Gems/1.8/gems/dm-core-1.0.2/lib/dm-core/query.rb:568:in slice' from /Library/Ruby/Gems/1.8/gems/dm-core-1.0.2/lib/dm-core/collection.rb:1413:insliced_query'
from /Library/Ruby/Gems/1.8/gems/dm-core-1.0.2/lib/dm-core/collection.rb:400:in `[]'
from (irb):2

---

Created by pathsny (at gmail) - 2010-10-25 03:08:00 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/1434

:unique and :unique_index merge causes some inconsistencies

For a more complete look, see:

http://gist.github.com/434435

To summarize briefly:

If the @:unique@ option is used on more than one properties, the unique indicies created in the database and the validations created are either

1. Inconsistent with each other
2. Result in redundant queries being issued and/or redundant indicies being created

---

Created by Jonathan Stott (namelessjon) - 2010-06-11 13:18:17 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/1316

OR conditions cannot be used in chaining

I have two classes

class A
has n, :bs
end

class B
belongs_to :a
end

Now I define a method in class A.

def active_bs
bs.all(:start_on.lte => Date.today, :end_on.gt => Date.today) + A.all(:start_on.lte => Date.today, :end_on => nil)
end

works fine

Now if I need to chain this with one defined in B, say
def good
all(:good => true)
end

A.new.active_bs.good wouldn't work. It will pretty much the same as calling B.good

Any thoughts? a bug or I use it in a wrong way?

Getting error "stack level too deep" if class contains word "fields"

Very strange bug, I am not sure if "fields" is a reserved word in DM.

A has many B, B is referenced as :fields in A
C has many D, C is referenced as :fields in C
A has many C

Run the attached file will give "stack level too deep" error, but if change the hash :field with :flds or :props etc, it works.

---

Created by Sean - 2010-02-27 17:53:09 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/1208

JDBC Data Type Error - PostgreSQL JDBC Adapter

Here's the Gist with the trace.

http://gist.github.com/433536

'njoy,
Mark

---

Created by Mark Cotner - 2010-06-10 19:55:13 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/1314

finding over collections that include discriminators

when trying to do a find on a discriminator field that has not been saved, I don't find the item
https://gist.github.com/716637

this works fine if the object has been saved

---

Created by pathsny (at gmail) - 2010-11-26 14:12:38 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/1451

validations should only be run for loaded lazy attributes

Currently when a validation runs, it gets all the values from the database, then never saves them because of course they're not dirty.

I found this strange, so thought I'd submit a ticket. I expected that it would skip validation on lazy attributes of non-new rows. The current method may be intentional, I don't know.

It would be less frustrating if lazy attributes defaulted to being in the same group, or had some way to know all were being requested and getting them all. My table has 10 text fields, so issues 10 select queries each time I update a row.

---

Created by Kevin Watt - 2010-07-28 05:54:54 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/1363

Conversion to Time from sqlite3

the sqlite3 adapter appears to ignore the timezone (uses local time) when retrieving records:

require 'rubygems'
require 'dm-core'

class Foo < Object
  include DataMapper::Resource

  property :id,       Serial
  property :birthday, Time
end

DataMapper.setup(:default, "sqlite3://box.db")
Foo.auto_migrate!

t = Time.now.utc
puts t
# Wed Jul 15 01:21:09 UTC 2009

f = Foo.new
f.birthday = t
f.save

puts Foo.first.birthday
# Wed Jul 15 01:21:09 -0700 2009

---

Created by Rich Collins - 2009-07-15 01:23:39 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/974

Ability to have non-primary key Serial properties

One should be able to create a field whose value defaults to being a guaranteed unique value.

Most databases have methods for creating guaranteed-unique default values that are not primary keys. For example, Postgres has SERIAL, SQLite has AUTOINCREMENT, MySQL has AUTO_INCREMENT, Mongo has ObjectIDs, etc. It would be useful to be able to set a property's default value to be unique without making it a primary key or imposing a uniqueness constraint on the field.

Currently, specifying property :id, Serial, :key => false, :unique => false will still generate a primary key and a uniqueness constraint on the field. It would be very useful if this would work as expected.

---

Created by Joshua Griffith - 2011-02-08 02:48:56 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/1483

first_or_new through associations doesn't act as expected

if you use first_or_new through an association, like the following:

user = User.new
p1 = user.post.new
p2 = user.post.new
p1.locations.first_or_new(:lat => lat, :lng => lng)
p2.locations.first_or_new(:lat => lat, :lng => lng)
user.save

2 locations are created with the same lat/lng... i feel like it would be ideal if first_or_new on an association would wait until it saves before calling first(), that way this situation would only create 1 location and both posts would refer to it

---

Created by handler - 2010-11-18 17:03:32 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/1448

allow_nil => false produces "may not be NULL (Sqlite3Error)"

allow_nil => false does not produces a validation error on nil values but when saving to the database a null constraint violation shows up. it is loosely related to #1136

http://gist.github.com/247052

---

Created by kristian - 2009-12-02 08:46:31 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/1140

[jruby] do_oracle: not showing parameter values in debug log output

Reproducible with:

• Oracle 10g (OS X)

Example debug log output:

  DEBUG - [25/Mar/2011 17:56:52] "(0.002) SELECT "ID", "CODE", "NAME" FROM "LANGUAGES" WHERE ("CODE" = ?)"
  DEBUG - [25/Mar/2011 17:56:52] "(0.083) SELECT "ID", "LANGUAGE_ID", "LOCATION_ID", "TITLE", "BODY" FROM "LOCATION_TRANSLATIONS" WHERE ("LOCATION_ID" IN (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)) ORDER BY "ID""

@Raimonds can you take this on? or do you want me to look at it? Looks like the field reflection that's needed to get values is broken?

---

Created by Alex Coles - 2011-03-25 17:32:20 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/1500

Deleting parent fails after deleting all children. (unless a .reload is done on parent)

This ticket is being submitted at the request of dkubb on freenode/datamapper.

The issue is with deleting a record that has child records. Even after deleting all of the parents records in the join table the destroy still fails. I was able to work around this (under the advice of dkubb) by adding a .reload before finally destroying the parent.

In the mysql console I can see the constraings on the join table. From the console I am able to successfully delete the child records and then the parent.

 @doc = Document.get(1)
begin
Document.transaction do
  #this is a simple app, only 2 models and one Resource/model
  #the following executes successfully
  unless @doc.document_tags.destroy
    raise 'document tags failed to be destroyed'
  end

  #the following fails unless its changed to @doc.reload.destroy
  unless @doc.destroy
    raise 'document destroy failed'
  end
end
rescue StandardError => e
  puts e
end

Please contact me on freenode if you require any additional information. -dev2

---

Created by dev2 - 2010-09-10 15:04:02 UTC

Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/1405