datamapper/dm-rails

Integrate DataMapper with Rails 3

dm-rails's Issues

Is dm-rails affected by the latest Rails security vulnerability?

If so can we expect a fix soon? The vulnerability is outlined here:

https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-security/1h2DR63ViGo

dm-rails is broken

rails new project_name -m http://datamapper.org/templates/rails.rb
cd project_name
rails g scaffold user name:string
rake db:automigrate

->

can't convert nil into String
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/data_objects-0.10.6/lib/data_objects/connection.rb:79:in `initialize'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/data_objects-0.10.6/lib/data_objects/connection.rb:79:in `new'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/data_objects-0.10.6/lib/data_objects/pooling.rb:177:in `block in new'
<internal:prelude>:10:in `synchronize'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/data_objects-0.10.6/lib/data_objects/pooling.rb:172:in `new'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/data_objects-0.10.6/lib/data_objects/pooling.rb:119:in `new'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/data_objects-0.10.6/lib/data_objects/connection.rb:68:in `new'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/dm-do-adapter-1.1.0/lib/dm-do-adapter/adapter.rb:251:in `open_connection'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/dm-transactions-1.1.0/lib/dm-transactions/adapters/dm-do-adapter.rb:69:in `open_connection'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/dm-do-adapter-1.1.0/lib/dm-do-adapter/adapter.rb:276:in `with_connection'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/dm-do-adapter-1.1.0/lib/dm-do-adapter/adapter.rb:33:in `select'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/dm-migrations-1.1.0/lib/dm-migrations/adapters/dm-sqlite-adapter.rb:43:in `table_info'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/dm-migrations-1.1.0/lib/dm-migrations/adapters/dm-sqlite-adapter.rb:18:in `storage_exists?'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/dm-migrations-1.1.0/lib/dm-migrations/auto_migration.rb:63:in `storage_exists?'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/dm-migrations-1.1.0/lib/dm-migrations/auto_migration.rb:118:in `storage_exists?'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/dm-constraints-1.1.0/lib/dm-constraints/migrations.rb:36:in `auto_migrate_down_constraints!'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/dm-migrations-1.1.0/lib/dm-migrations/auto_migration.rb:45:in `block in repository_execute'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/dm-core-1.1.0/lib/dm-core/support/descendant_set.rb:66:in `block in each'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/dm-core-1.1.0/lib/dm-core/support/subject_set.rb:212:in `block in each'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/dm-core-1.1.0/lib/dm-core/support/ordered_set.rb:321:in `block in each'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/dm-core-1.1.0/lib/dm-core/support/ordered_set.rb:321:in `each'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/dm-core-1.1.0/lib/dm-core/support/ordered_set.rb:321:in `each'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/dm-core-1.1.0/lib/dm-core/support/subject_set.rb:212:in `each'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/dm-core-1.1.0/lib/dm-core/support/descendant_set.rb:65:in `each'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/dm-migrations-1.1.0/lib/dm-migrations/auto_migration.rb:44:in `repository_execute'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/dm-constraints-1.1.0/lib/dm-constraints/migrations.rb:10:in `auto_migrate!'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/dm-rails-1.1.0/lib/dm-rails/railties/database.rake:38:in `block (3 levels) in <top (required)>'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/dm-rails-1.1.0/lib/dm-rails/railties/database.rake:37:in `each'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/dm-rails-1.1.0/lib/dm-rails/railties/database.rake:37:in `block (2 levels) in <top (required)>'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/rake-0.9.2/lib/rake/task.rb:205:in `call'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/rake-0.9.2/lib/rake/task.rb:205:in `block in execute'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/rake-0.9.2/lib/rake/task.rb:200:in `each'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/rake-0.9.2/lib/rake/task.rb:200:in `execute'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/rake-0.9.2/lib/rake/task.rb:158:in `block in invoke_with_call_chain'
/home/nwmcsween/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/monitor.rb:201:in `mon_synchronize'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/rake-0.9.2/lib/rake/task.rb:151:in `invoke_with_call_chain'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/rake-0.9.2/lib/rake/task.rb:144:in `invoke'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/rake-0.9.2/lib/rake/application.rb:112:in `invoke_task'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/rake-0.9.2/lib/rake/application.rb:90:in `block (2 levels) in top_level'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/rake-0.9.2/lib/rake/application.rb:90:in `each'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/rake-0.9.2/lib/rake/application.rb:90:in `block in top_level'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/rake-0.9.2/lib/rake/application.rb:129:in `standard_exception_handling'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/rake-0.9.2/lib/rake/application.rb:84:in `top_level'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/rake-0.9.2/lib/rake/application.rb:62:in `block in run'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/rake-0.9.2/lib/rake/application.rb:129:in `standard_exception_handling'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/rake-0.9.2/lib/rake/application.rb:59:in `run'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/gems/rake-0.9.2/bin/rake:32:in `<top (required)>'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/bin/rake:19:in `load'
/home/nwmcsween/.rvm/gems/ruby-1.9.2-p180/bin/rake:19:in `<main>'
Tasks: TOP => db:automigrate

Rails 3.0 compatibility

It seems like dm-rails 1.2 is the only version that is compatible with ruby 1.9.3, but dm-rails depends on rails ~> 3.1.0, is that neccesary? could it support rails ~> 3.0.10 ?

before :save and before :create hooks are not working

I am using dm-rails version 1.2.0 with dm-core version 1.2.0 and rails version 3.1.3.

In my model, when I define before :valid? or before :destroy, they work without any problem but before :save or before :create does not work.

Please let me know what else do I need to submit to this issue.

Datamapper session argument error in rails 3.2 & 3.1

I created a new rails 3.2.6 app with the template provided in the README file and tried to use the sessions in database.

This is the change I made to my session_store.rb initializer file

require 'dm-rails/session_store'
MyApp::Application.config.session_store Rails::DataMapper::SessionStore

I am getting this error when I try to access any of the routes.

ArgumentError (wrong number of arguments (4 for 3)):
  rack (1.4.1) lib/rack/session/abstract/id.rb:322:in `commit_session'
  rack (1.4.1) lib/rack/session/abstract/id.rb:206:in `context'
  rack (1.4.1) lib/rack/session/abstract/id.rb:200:in `call'
  actionpack (3.2.6) lib/action_dispatch/middleware/cookies.rb:338:in `call'
  actionpack (3.2.6) lib/action_dispatch/middleware/callbacks.rb:28:in `call'
  activesupport (3.2.6) lib/active_support/callbacks.rb:408:in `_run__424927580__call__859012901__callbacks'
  org/jruby/RubyKernel.java:2076:in `send'
  activesupport (3.2.6) lib/active_support/callbacks.rb:405:in `__run_callback'
  activesupport (3.2.6) lib/active_support/callbacks.rb:390:in `_run_call_callbacks'
  org/jruby/RubyKernel.java:2076:in `send'
  activesupport (3.2.6) lib/active_support/callbacks.rb:81:in `run_callbacks'
  actionpack (3.2.6) lib/action_dispatch/middleware/callbacks.rb:27:in `call'
  actionpack (3.2.6) lib/action_dispatch/middleware/reloader.rb:65:in `call'
  actionpack (3.2.6) lib/action_dispatch/middleware/remote_ip.rb:31:in `call'
  actionpack (3.2.6) lib/action_dispatch/middleware/debug_exceptions.rb:16:in `call'
  actionpack (3.2.6) lib/action_dispatch/middleware/show_exceptions.rb:56:in `call'
  railties (3.2.6) lib/rails/rack/logger.rb:26:in `call_app'
  railties (3.2.6) lib/rails/rack/logger.rb:16:in `call'
  actionpack (3.2.6) lib/action_dispatch/middleware/request_id.rb:22:in `call'
  rack (1.4.1) lib/rack/methodoverride.rb:21:in `call'
  rack (1.4.1) lib/rack/runtime.rb:17:in `call'
  activesupport (3.2.6) lib/active_support/cache/strategy/local_cache.rb:72:in `call'
  rack (1.4.1) lib/rack/lock.rb:15:in `call'
  actionpack (3.2.6) lib/action_dispatch/middleware/static.rb:62:in `call'
  railties (3.2.6) lib/rails/engine.rb:479:in `call'
  railties (3.2.6) lib/rails/application.rb:220:in `call'
  file:jruby-rack (1.1.7) lib/jruby-rack-1.1.7.jar!/rack/handler/servlet.rb:21:in `call'

I am using jruby version 1.6.7.2.

I have seen other issue #28 regarding this problem which has been closed but we are still seeing it.

Ignore

Ignore. Too many github windows open. This was meant for snorby.

rails3 with cache_cache classes = false causes problems with many 2 many associations

I have isolated a problem with rails3 and many 2 many associations in this sample rails3 app: git://github.com/mbj/bugapp
It is NOT reproducible under a non rails3 cache_classes = false environment.

The app is featuring two models:

class Article
  include DataMapper::Resource
  property :id, Serial
  has n, :persons, :through => Resource
end

class Person
  include DataMapper::Resource
  property :id, Serial
  has n, :articles, :through => Resource
end

One Controller:

class ApplicationController < ActionController::Base
  protect_from_forgery

  # routed from GET /a, creates some records needed for demonstration
  # you have to hit it to get this demo working

  def create_person_and_articles
    person = Person.create
    person.articles.create
    person.articles.create
    head :ok
  end

  # routet from GET /b, is basically a noop, (Articles are linked already), but
  # causes problems when classes got reloaded! (so hit at least twice after a fresh start)

  def assing_articles_another_time
    person = Person.first
    person.attributes = { :articles => Article.all }
    person.save
    head :ok
  end
end

Hitting /b after /a results in the following exception where sqlite complains over the already existing join record. DataMapper tries to create the join records, where it should not.

mbj@seon ~/devel/bugapp $ rake db:automigrate
(in /home/mbj/devel/bugapp)
[datamapper] Finished auto_migrate! for :default repository '/home/mbj/devel/bugapp/db/development.sqlite3'
mbj@seon ~/devel/bugapp $ ./script/rails s -p 4003
=> Booting WEBrick
=> Rails 3.0.0.rc application starting in development on http://0.0.0.0:4003
=> Call with -d to detach
=> Ctrl-C to shutdown server
[datamapper] Setting up the "development" environment:
[datamapper] Setting up :default repository: '/home/mbj/devel/bugapp/db/development.sqlite3' on sqlite3
[2010-08-10 23:00:02] INFO  WEBrick 1.3.1
[2010-08-10 23:00:02] INFO  ruby 1.9.2 (2010-07-11) [x86_64-linux]
[2010-08-10 23:00:02] INFO  WEBrick::HTTPServer#start: pid=2919 port=4003

Started GET "/a" for 93.131.158.195 at 2010-08-10 23:00:14 +0200
  Processing by ApplicationController#create_person_and_articles as HTML
  SQL (38.603ms)  INSERT INTO "people" DEFAULT VALUES
  SQL (29.642ms)  INSERT INTO "articles" DEFAULT VALUES
  SQL (0.124ms)  SELECT "article_id", "person_id" FROM "article_people" WHERE ("person_id" = 1 AND "article_id" = 1) ORDER BY "article_id", "person_id" LIMIT 1
  SQL (6.635ms)  INSERT INTO "article_people" ("article_id", "person_id") VALUES (1, 1)
  SQL (11.762ms)  INSERT INTO "articles" DEFAULT VALUES
  SQL (0.101ms)  SELECT "article_id", "person_id" FROM "article_people" WHERE ("person_id" = 1 AND "article_id" = 2) ORDER BY "article_id", "person_id" LIMIT 1
  SQL (7.455ms)  INSERT INTO "article_people" ("article_id", "person_id") VALUES (2, 1)
Completed 200 OK in 150ms


Started GET "/b" for 93.131.158.195 at 2010-08-10 23:00:17 +0200
  Processing by ApplicationController#assing_articles_another_time as HTML
  SQL (0.079ms)  SELECT "id" FROM "people" ORDER BY "id" LIMIT 1
  SQL (0.137ms)  SELECT "articles"."id" FROM "articles" INNER JOIN "article_people" ON "articles"."id" = "article_people"."article_id" INNER JOIN "people" ON "article_people"."person_id" = "people"."id" WHERE "article_people"."person_id" = 1 GROUP BY "articles"."id" ORDER BY "articles"."id"
  SQL (0.034ms)  SELECT "id" FROM "articles" ORDER BY "id"
columns article_id, person_id are not unique (code: 19, sql state: , query: INSERT INTO "article_people" ("article_id", "person_id") VALUES (1, 1), uri: sqlite3:///home/mbj/devel/bugapp/db/development.sqlite3)
Completed   in 13ms

DataObjects::IntegrityError (columns article_id, person_id are not unique):
  app/controllers/application_controller.rb:14:in `assing_articles_another_time'

Setting cache_classes = true, eliminates the problem. Running in rails console also. I'd expect the bug somewhere in the model reload code.

Note about running my example bugapp, you need to use dm-rails from git://github.com/datamapper/dm-rails, see Gemfile. dm-rails-1.0.0 from rubyforge is not yet compatible with rails3.

If you feel this bugreport would fit better in another bugtracker (like rails one under rails.lighthouseapp.com) please let me know I will post this issue there.

ruby -v
ruby 1.9.2dev (2010-07-11 revision 28618) x86_64-linux

---

Created by mbj - 2010-08-10 21:49:08 UTC

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

Will dm-rails be upgraded to fix the recent security vulnerability?

This is the vulnerability I'm talking about: http://weblog.rubyonrails.org/2013/1/8/Rails-3-2-11-3-1-10-3-0-19-and-2-3-15-have-been-released/

If not, can someone tell me how to upgrade to the latest patched version of rails separately while still using dm-rails?

Automigration failure

On a fresh install of Ubuntu 11.04, I've been toying with this, cannot automigrate on new project or existing project where automigrate worked friday. Full message and trace at bottom.

Rails version 3.0.9 is installed
the dm-rails template uses 3.0.4, I tried installing that, getting same error.

automigration fails

/.rvm/gems/ruby-1.9.2-p180/gems/dm-rails-1.1.0/lib/dm-rails/railties/database.rake:72:in `block (2 levels) in <top (required)>'
rake aborted!
can't convert nil into String

Full message:

rake db:automigrate                               | 15:15:56 |
WARNING: 'task :t, arg, :needs => [deps]' is deprecated.  Please use 'task :t, [args] => [deps]' instead.
    at /home/qz/.rvm/gems/ruby-1.9.2-p180/gems/dm-rails-1.1.0/lib/dm-rails/railties/database.rake:67:in `block (2 levels) in <top (required)>'
WARNING: 'task :t, arg, :needs => [deps]' is deprecated.  Please use 'task :t, [args] => [deps]' instead.
    at /home/qz/.rvm/gems/ruby-1.9.2-p180/gems/dm-rails-1.1.0/lib/dm-rails/railties/database.rake:72:in `block (2 levels) in <top (required)>'
rake aborted!
can't convert nil into String

Trace:

------ rake db:automigrate --trace                       | 15:22:08 |
WARNING: 'task :t, arg, :needs => [deps]' is deprecated.  Please use 'task :t, [args] => [deps]' instead.
    at /home/qz/.rvm/gems/ruby-1.9.2-p180/gems/dm-rails-1.1.0/lib/dm-rails/railties/database.rake:67:in `block (2 levels) in <top (required)>'
WARNING: 'task :t, arg, :needs => [deps]' is deprecated.  Please use 'task :t, [args] => [deps]' instead.
    at /home/qz/.rvm/gems/ruby-1.9.2-p180/gems/dm-rails-1.1.0/lib/dm-rails/railties/database.rake:72:in `block (2 levels) in <top (required)>'
** Invoke db:automigrate (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute db:automigrate
rake aborted!
can't convert nil into String
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/data_objects-0.10.6/lib/data_objects/connection.rb:79:in `initialize'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/data_objects-0.10.6/lib/data_objects/connection.rb:79:in `new'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/data_objects-0.10.6/lib/data_objects/pooling.rb:177:in `block in new'
<internal:prelude>:10:in `synchronize'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/data_objects-0.10.6/lib/data_objects/pooling.rb:172:in `new'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/data_objects-0.10.6/lib/data_objects/pooling.rb:119:in `new'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/data_objects-0.10.6/lib/data_objects/connection.rb:68:in `new'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/dm-do-adapter-1.1.0/lib/dm-do-adapter/adapter.rb:251:in `open_connection'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/dm-transactions-1.1.0/lib/dm-transactions/adapters/dm-do-adapter.rb:69:in `open_connection'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/dm-do-adapter-1.1.0/lib/dm-do-adapter/adapter.rb:276:in `with_connection'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/dm-do-adapter-1.1.0/lib/dm-do-adapter/adapter.rb:33:in `select'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/dm-migrations-1.1.0/lib/dm-migrations/adapters/dm-sqlite-adapter.rb:43:in `table_info'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/dm-migrations-1.1.0/lib/dm-migrations/adapters/dm-sqlite-adapter.rb:18:in `storage_exists?'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/dm-migrations-1.1.0/lib/dm-migrations/auto_migration.rb:63:in `storage_exists?'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/dm-migrations-1.1.0/lib/dm-migrations/auto_migration.rb:118:in `storage_exists?'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/dm-constraints-1.1.0/lib/dm-constraints/migrations.rb:36:in `auto_migrate_down_constraints!'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/dm-migrations-1.1.0/lib/dm-migrations/auto_migration.rb:45:in `block in repository_execute'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/dm-core-1.1.0/lib/dm-core/support/descendant_set.rb:66:in `block in each'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/dm-core-1.1.0/lib/dm-core/support/subject_set.rb:212:in `block in each'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/dm-core-1.1.0/lib/dm-core/support/ordered_set.rb:321:in `block in each'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/dm-core-1.1.0/lib/dm-core/support/ordered_set.rb:321:in `each'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/dm-core-1.1.0/lib/dm-core/support/ordered_set.rb:321:in `each'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/dm-core-1.1.0/lib/dm-core/support/subject_set.rb:212:in `each'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/dm-core-1.1.0/lib/dm-core/support/descendant_set.rb:65:in `each'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/dm-migrations-1.1.0/lib/dm-migrations/auto_migration.rb:44:in `repository_execute'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/dm-constraints-1.1.0/lib/dm-constraints/migrations.rb:10:in `auto_migrate!'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/dm-rails-1.1.0/lib/dm-rails/railties/database.rake:38:in `block (3 levels) in <top (required)>'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/dm-rails-1.1.0/lib/dm-rails/railties/database.rake:37:in `each'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/dm-rails-1.1.0/lib/dm-rails/railties/database.rake:37:in `block (2 levels) in <top (required)>'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/rake-0.9.2/lib/rake/task.rb:205:in `call'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/rake-0.9.2/lib/rake/task.rb:205:in `block in execute'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/rake-0.9.2/lib/rake/task.rb:200:in `each'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/rake-0.9.2/lib/rake/task.rb:200:in `execute'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/rake-0.9.2/lib/rake/task.rb:158:in `block in invoke_with_call_chain'
/home/qz/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/monitor.rb:201:in `mon_synchronize'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/rake-0.9.2/lib/rake/task.rb:151:in `invoke_with_call_chain'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/rake-0.9.2/lib/rake/task.rb:144:in `invoke'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/rake-0.9.2/lib/rake/application.rb:112:in `invoke_task'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/rake-0.9.2/lib/rake/application.rb:90:in `block (2 levels) in top_level'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/rake-0.9.2/lib/rake/application.rb:90:in `each'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/rake-0.9.2/lib/rake/application.rb:90:in `block in top_level'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/rake-0.9.2/lib/rake/application.rb:129:in `standard_exception_handling'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/rake-0.9.2/lib/rake/application.rb:84:in `top_level'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/rake-0.9.2/lib/rake/application.rb:62:in `block in run'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/rake-0.9.2/lib/rake/application.rb:129:in `standard_exception_handling'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/rake-0.9.2/lib/rake/application.rb:59:in `run'
/home/qz/.rvm/gems/ruby-1.9.2-p180/gems/rake-0.9.2/bin/rake:32:in `<top (required)>'
/home/qz/.rvm/gems/ruby-1.9.2-p180/bin/rake:19:in `load'
/home/qz/.rvm/gems/ruby-1.9.2-p180/bin/rake:19:in `<main>'
Tasks: TOP => db:automigrate

1.3.0

Are there any plans to release 1.3.0?

Sessions do not save

Sessions in my Rails 3 app are not saving.

I'm seeing a validation error on the session:
errors={:updated_at=>["Updated at must be of type DateTime"]}

However, I have no idea why DataMapper isn't simply casting this properly. I can't get the same behavior in a standalone DM test script.

I'm using ruby 1.9.2. My Gemfile looks like this:

source "http://rubygems.org"
source "http://gems.github.com"

gem 'rake', '0.8.7'
gem 'rails', '3.0.8'

DM_VERSION = '1.1.0'

gem "dm-postgres-adapter", DM_VERSION
gem 'dm-aggregates', DM_VERSION
gem 'dm-constraints', DM_VERSION
gem 'dm-validations', DM_VERSION
gem 'dm-migrations', DM_VERSION
gem 'dm-timestamps', DM_VERSION
gem 'dm-types', DM_VERSION
gem 'dm-transactions', DM_VERSION
gem 'dm-serializer', DM_VERSION

gem 'dm-rails', DM_VERSION

[patch] rails-datamapper: dry up and add rails generators

in past I copied a lot of generator for rails around and in dm-more/rails_datamapper I saw this again. so here is one possible solution to dry up generators. and then I just added two more generators.

the idea is to introduce overlay directories for searching template files. this allows reusing existing generators and tell them where to search for the templates files and be able to replace some template files with local versions.

the overlay directories can be also given as command line option which allows projects to keep some project specific templates around somewhere.

in case you like this patch I happy to write up the last missing generator for dm-scaffold which uses unit-test instead of rspec.

---

Created by kristian - 2009-07-13 12:50:30 UTC

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

composite keys in a rails project

Im not sure if this is caused by dm-rails.
The code is here:
https://gist.github.com/1011318

You can execute the _setup.sh (copy & paste to terminal) which should setup a rails 3 project with a Gemfile, rspec, the models and one spec. The spec should fail (at least when i execute it it fails with "expected: nil got: nil").

It seems like during the DataMapper.auto_migrate! the columns in the Database for Friendship.request are not created. In a standalone test with the same models though it works and Friendship has one :request_sender_id and :request_receiver_id property. The standalone-spec is here: https://gist.github.com/1010908

Am i doing something wrong or is this a dm-rails/dm-migration/whatever bug?

Catching up to Rails 3.1.0

I'm trying to update my applications to rails 3.1.0, and create some new apps.

I see the gemspec points to 3.1.0, but the template (option "-m http://datamapper.org/templates/rails.rb") listed in the instructions only lists rails 3.0.4.

What needs to be done? I'm only at a level where using the template is feasible (skill and time-wise), but I'm willing to help out. dm-rails + rails 3.1 is not a smooth workflow for me at this point.

db:automigrate fails dm 1.3.0 - beta and mysql

Hello,
I'm running a rails 3.2.1 project with dm-* 1.3.0.beta and using mysql database. When I run db:automigrate it fails:

Tried in a Windows and Linux environment.

Can't create table 'mytable.#sql-618_4d' (errno: 150)
C:/Ruby192/lib/ruby/gems/1.9.1/bundler/gems/dm-do-adapter-d295d77f3e4b/lib/dm-do-adapter/adapter.rb:63:in execute_non_query' C:/Ruby192/lib/ruby/gems/1.9.1/bundler/gems/dm-do-adapter-d295d77f3e4b/lib/dm-do-adapter/adapter.rb:63:inblock in execute'
C:/Ruby192/lib/ruby/gems/1.9.1/bundler/gems/dm-do-adapter-d295d77f3e4b/lib/dm-do-adapter/adapter.rb:276:in with_connection' C:/Ruby192/lib/ruby/gems/1.9.1/bundler/gems/dm-do-adapter-d295d77f3e4b/lib/dm-do-adapter/adapter.rb:61:inexecute'
C:/Ruby192/lib/ruby/gems/1.9.1/bundler/gems/dm-constraints-67cfad8018ed/lib/data_mapper/constraints/adapters/do_adapter.rb:71:in create_relationship_ constraint' C:/Ruby192/lib/ruby/gems/1.9.1/bundler/gems/dm-constraints-67cfad8018ed/lib/data_mapper/constraints/migrations/relationship.rb:19:inauto_migrate_con
straints_up'
C:/Ruby192/lib/ruby/gems/1.9.1/bundler/gems/dm-constraints-67cfad8018ed/lib/data_mapper/constraints/migrations/model.rb:16:in block in auto_migrate_c onstraints_up' C:/Ruby192/lib/ruby/gems/1.9.1/bundler/gems/dm-core-3aee0ec24233/lib/dm-core/support/subject_set.rb:210:inblock in each'
C:/Ruby192/lib/ruby/gems/1.9.1/bundler/gems/dm-core-3aee0ec24233/lib/dm-core/support/ordered_set.rb:319:in block in each' C:/Ruby192/lib/ruby/gems/1.9.1/bundler/gems/dm-core-3aee0ec24233/lib/dm-core/support/ordered_set.rb:319:ineach'
C:/Ruby192/lib/ruby/gems/1.9.1/bundler/gems/dm-core-3aee0ec24233/lib/dm-core/support/ordered_set.rb:319:in each' C:/Ruby192/lib/ruby/gems/1.9.1/bundler/gems/dm-core-3aee0ec24233/lib/dm-core/support/subject_set.rb:210:ineach'
C:/Ruby192/lib/ruby/gems/1.9.1/bundler/gems/dm-constraints-67cfad8018ed/lib/data_mapper/constraints/migrations/model.rb:15:in `auto_migrate_constraint

Regards,
Carlos

1.2.1: need to check for nil variables in configuration.rb

I'm debugging why my snorby install is futzing up, dm-rails is dying when trying to invoke a method on a nil variable. It would be useful to check each operation completed properly and then proceed with the rest of the dm-rails code.

This method on line 23:

22        def repositories
23          @repositories ||= raw.reject { |k,v| k =~ /defaults/ }.inject({}) do |repositories, pair|
24            environment, config = pair.first, pair.last
25            repositories[environment] = begin

results in this error when the operation didn't work:

host:/usr/local/snorby root# bundle exec rake -t -v snorby:setup
syck has been removed, psych is used instead
** Invoke snorby:setup (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute snorby:setup
** Invoke secret (first_time)
** Execute secret
deadbeefc0ff3deadbeefc0ff3deadbeefc0ff3deadbeefc0ff3deadbeefc0ff3deadbeefc0ff3deadbeefc0ff3deadbeef
** Invoke db:create (first_time)
** Invoke environment
** Execute db:create
rake aborted!
undefined method `reject' for nil:NilClass
/usr/local/lib/ruby/gems/2.0.0/gems/dm-rails-1.2.1/lib/dm-rails/configuration.rb:23:in `repositories'
/usr/local/lib/ruby/gems/2.0.0/gems/dm-rails-1.2.1/lib/dm-rails/railties/database.rake:18:in `block (2 levels) in <top (required)>'
/usr/local/lib/ruby/2.0.0/rake/task.rb:228:in `call'
/usr/local/lib/ruby/2.0.0/rake/task.rb:228:in `block in execute'
/usr/local/lib/ruby/2.0.0/rake/task.rb:223:in `each'
/usr/local/lib/ruby/2.0.0/rake/task.rb:223:in `execute'
/usr/local/lib/ruby/2.0.0/rake/task.rb:166:in `block in invoke_with_call_chain'
/usr/local/lib/ruby/2.0.0/monitor.rb:211:in `mon_synchronize'
/usr/local/lib/ruby/2.0.0/rake/task.rb:159:in `invoke_with_call_chain'
/usr/local/lib/ruby/2.0.0/rake/task.rb:152:in `invoke'
/usr/local/snorby.2.6.2/lib/tasks/snorby.rake:30:in `block (2 levels) in <top (required)>'
/usr/local/lib/ruby/2.0.0/rake/task.rb:228:in `call'
/usr/local/lib/ruby/2.0.0/rake/task.rb:228:in `block in execute'
/usr/local/lib/ruby/2.0.0/rake/task.rb:223:in `each'
/usr/local/lib/ruby/2.0.0/rake/task.rb:223:in `execute'
/usr/local/lib/ruby/2.0.0/rake/task.rb:166:in `block in invoke_with_call_chain'
/usr/local/lib/ruby/2.0.0/monitor.rb:211:in `mon_synchronize'
/usr/local/lib/ruby/2.0.0/rake/task.rb:159:in `invoke_with_call_chain'
/usr/local/lib/ruby/2.0.0/rake/task.rb:152:in `invoke'
/usr/local/lib/ruby/2.0.0/rake/application.rb:143:in `invoke_task'
/usr/local/lib/ruby/2.0.0/rake/application.rb:101:in `block (2 levels) in top_level'
/usr/local/lib/ruby/2.0.0/rake/application.rb:101:in `each'
/usr/local/lib/ruby/2.0.0/rake/application.rb:101:in `block in top_level'
/usr/local/lib/ruby/2.0.0/rake/application.rb:110:in `run_with_threads'
/usr/local/lib/ruby/2.0.0/rake/application.rb:95:in `top_level'
/usr/local/lib/ruby/2.0.0/rake/application.rb:73:in `block in run'
/usr/local/lib/ruby/2.0.0/rake/application.rb:160:in `standard_exception_handling'
/usr/local/lib/ruby/2.0.0/rake/application.rb:70:in `run'
/usr/local/lib/ruby/gems/2.0.0/gems/rake-0.9.6/bin/rake:37:in `<top (required)>'
/usr/local/bin/rake:23:in `load'
/usr/local/bin/rake:23:in `<main>'
Tasks: TOP => db:create

This post includes code fixes which would be useful.

http://stackoverflow.com/questions/12705545/ruby-on-rails-params-is-nil-undefined-method-for-nilnilclass

Rails 3.2 compatibility

dm-rails 1.2.0 is compatible with rails ~3.1.0.

How about ~3.2.0?

Railtie breaks migrations

You can't use migrations in Rails 3 because dm-rails adds a benchmarking decorator to the adapter. This means that DataMapper::Migration#initialize (lines 24-30) throw a RuntimeError "Unsupported Migration Adapter Rails::DataMapper::Adapters::BenchmarkingAdapter".

Conflicting file here:

http://github.com/datamapper/dm-more/blob/master/dm-migrations/lib/dm-migrations/migration.rb

This is the workaround I'm using:

module Rails
  module DataMapper
    class Railtie
      def setup_adapter_cascade(app)
        # remove the BenchmarkingAdapter from the adapter cascade
      end
    end
  end
end

Models in Rails Engines Erroring (1.2.0, I think)

Originally opened by @jkestr: datamapper/dm-core#175

I've been running into an issue with existing models and engines I have built from previous versions of DataMapper.

It appears with 1.2.0, it is no longer possible to have models inside of an engine without explicitly calling #finalize on each model. Is this a known issue, and if so are there any work arounds?

DataMapper.finalize does not work in this context, as it does not see the models inside of the engines. I tried creating an initializer that calls finalize on each model, but I ran into issues with Devise not yet being loaded.

What did work was putting .finalize at the bottom of each model definition, but I would rather not have to do that, and I am sure it would only cause other issues with relationships and such.

Deprecation warnings with rake 0.9.0

I just built a new dev environment, and ended up with the brand-new rake 0.9.0. It causes some deprecation warnings in dm-rails:

WARNING: 'task :t, arg, :needs => [deps]' is deprecated. Please use 'task :t, [args] => [deps]' instead.
at /dm-rails-1.1.0/lib/dm-rails/railties/database.rake:67
WARNING: 'task :t, arg, :needs => [deps]' is deprecated. Please use 'task :t, [args] => [deps]' instead.
at /dm-rails-1.1.0/lib/dm-rails/railties/database.rake:72

Not sure if you can fix these without breaking any intended backwards compatibility, but just in case you wanted to know...

Dependencies are too restrictive

Right now dm-rails is depending on railties ~> 3.0.4, this means that even though Rails 3.1 is guaranteed to be API compatible (they claim to follow semver), dm-rails is not usable with Rails 3.1, for no good reason whatsoever.

The dependency should be relaxed to railties ~> 3.0.

gem dependency clash with rails 3.2.1

Hello

I'm new to the world of dm-rails, so this is probably just a newbee thing.

I found that following the instructions in the README failed due to a clash on activepack version requirements, as sass-rails wants actionpack version 3.1.x ...

jesse@Heart-of-Gold $ bundle install
Fetching source index for http://rubygems.org/
Bundler could not find compatible versions for gem "actionpack":
  In Gemfile:
    sass-rails (~> 3.1.5) ruby depends on
      actionpack (~> 3.1.0) ruby

    actionpack (3.2.1)

Commenting out the following lines and running 'bundle update' once more fixes it for now...

#group :assets do                                                                                                                          
#  gem 'sass-rails',   '~> 3.1.5'                                                                                                          
#  gem 'coffee-rails', '~> 3.1.1'                                                                                                          
#  gem 'uglifier', '>= 1.0.3'                                                                                                              
#end                                                                                                                                       

Railties 3.2 compatibility

Hi,

I wanted to use dm-rails in a project where I am already using railties ~> 3.2 which conflicts with the railties ~> 3.0 runtime_dependency.

Regards

Rails flash doesn't save properly in dm-rails Session

Flash in Rails doesn't work with the dm-rails session. The data property is never marked as dirty because the session data flash is modified as the same object.

Support for Rails 4?

Will this gem be updated to support Rails 4?

default_scope & dm-rails

Hi,

It is possible to use default_scope with dm-rails? e.g.

class Article < ActiveRecord::Base default_scope where(:published => true) end

or is there something similar I can use which has the same effect?

Bump Rails version to 3.2

I would submit a pull request but as far as I can tell its just a matter of updating the Gemfile, but I'm not sure how versioning requirements should be handled.

dm-rails should map empty Strings to nil, for Integer properties that allow_nil

I discovered an incompatibility in how dm-rails consumes empty Strings, from select/option form fields. When a select form field is left unselected, the submitted value is always an empty String. ActiveRecord would treat empty Strings as nil values, when populating attributes. dm-rails should not map all empty Strings to nil, but only for Integer properties that allows nil.

migrate task: Use Rails config.paths for location of migration files

Rails now allows configuration of an array of paths for the location of migration files. The path should not be hardcoded and instead the paths should be read from the configuration.

change (in load task):

FileList['db/migrate/*.rb'].each do |migration|

to:

paths = Rails.configuration.paths['db/migrate'].map { |p| p + '/*.rb' }
FileList[paths].each do |migration|

also in actual migrate task change:

migrate_task = if Dir['db/migrate/*.rb'].empty?

to:

migrate_task = if Rails.configuration.paths['db/migrate'].all? { |p| Dir[p + '/*.rb'].empty? }

dm-rails should be timezone aware

This is how activerecord works:

Time.zone = 'Athens'
Post.first.created_at # => Thu, 27 May 2010 19:28:01 EEST +03:00

Time.zone = 'London'
Post.first.created_at # => Thu, 27 May 2010 17:28:01 BST +01:00

Datamapper ignores timezone. So to achieve the same effect you need to use in_time_zone method on time fields, which isn't very handy.

---

Created by kgiszczak - 2010-05-27 17:37:20 UTC

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

rake spec failed

Hi,
here is my rake spec:
https://gist.github.com/995276

how to fix it?

Non-default repositories not being setup

When trying to use a repository other than the default, I'm getting the following error:

Adapter not set: parking. Did you forget to setup?

Here's my database.yml file:

parking_defaults: &parking_defaults
  adapter:  oracle
  host: server/database
  username: myusername
  password: mypassword

  development:
    <<: *parking_defaults
    repositories:
      parking:
        <<: *parking_defaults

I've setup my model to use the parking repository like so:

def self.default_repository_name
  :parking
end

and I've also set its table name explicitly:

storage_names[:parking] = 'TICKETTRANSACTION'

If I change both of the :parking symbols in the model to :default, everything works as expected.

active record config errors on app generation

rails 3.2.2

after generating a new rails app with

rails new project_name -m http://datamapper.org/templates/rails.rb

when trying to use the generators i got a error referencing active_record in the development.rb file in environments.

after commenting out the offending lines referencing active record:

LN 26: config.active_record.mass_assignment_sanitizer = :strict

LN 30: config.active_record.auto_explain_threshold_in_seconds = 0.5

I was able to use the generator to correctly generate a scaffold.

I believe the http://datamapper.org/templates/rails.rb script needs to be updated.

Thanks.

SessionStore does not write session if internals of session['flash'] are modified

SessionStore::Session.set_session gets the memorized session model instance from env, then updates session_data. However, session.dirty? is false even if the internals of the flash changed, because they were already modified by the flash object.

The fix seems to be to replace:

session = get_session_resource(env, sid)

with

session = find_session(sid)

to get a fresh copy.