【问题标题】:Rails - Seeding the database with nil instead of valuesRails - 用 nil 而不是值播种数据库
【发布时间】:2016-09-29 07:12:48
【问题描述】:

我在 Rails 4.2.3 中创建了一个应用程序 我正在尝试为数据库播种,但是在执行 rake db:migrate 之后,我在数据库表的字段中得到了 nil 值。我的seeds.rb 中唯一的一段代码是:

    User.create![{username: "test", password_digest: "test"}]

在我的 schema.rb 我有:

    create_table "users", force: :cascade do |t|
      t.string   "username"
      t.string   "password_digest"
      t.datetime "created_at",      null: false
      t.datetime "updated_at",      null: false
    end

我的用户模型是:

      class User < ActiveRecord::Base
        has_one :profile, dependent: :destroy
        has_many :todo_lists, dependent: :destroy
        has_many :todo_items, through: :todo_lists, source: :todo_items
      end

还有其他人遇到过同样的问题,例如 herehere,但我认为这些解决方案不适用于我的情况,因为我的任何模型中都没有任何 attr_accessor。

有人知道为什么会这样吗?

【问题讨论】:

  • 大括号类型很重要...改用User.create!( username: "test", password_digest: "test" )

标签: ruby-on-rails ruby-on-rails-4


【解决方案1】:

大括号类型很重要......

改用下面的

User.create!( username: "test", password_digest: "test" )

这告诉 Rails 创建一个用户,使用包含用户名“test”和密码“test”的哈希

您所拥有的是告诉 Rails 使用包含哈希 {}...

编辑:回复:使用[]

那是因为当你不使用() 但使用[] 时,ruby 必须猜测你的意思...... 您是将数组传递给方法还是在变量上调用数组索引方法? (如果括号中不是整数,则使用哈希索引)?

如果您将[] 放在单词create! 旁边(例如User.create![]),ruby 可能会将其解释为后者...例如,它正在寻找User 类上的变量@987654331 @... 然后尝试查找名为 {username: "test", password_digest: "test"}, {username: "test2", password_digest: "test2"} 的哈希的键,然后它会感到困惑,因为当您使用数组索引方法 [] 时,您应该只传递一个键来查找,而不是两个(@ 987654334@ 是第一个,{username: "test2", password_digest: "test2"} 是第二个)......因此给你一个错误,你试图传递 2 个参数而不是一个......但也只是使用错误的解释开始。

这两者都不是你想要的......

如果您在 []create! 之间留有空格,那么 ruby​​ 更有可能将 [] 解释为传递给方法的参数...然后它会触发不同的错误。

为了明确 - 始终使用空格...或使用括号 () 在传递可能以这种方式不明确的参数时。

【讨论】:

  • 谢谢 Taryn - 这真的很有帮助。快速提问 - 我很困惑,因为在我关注的课程中,我们有一个示例,我们使用以下代码创建两个用户:User.create! [ {username: "test", password_digest: "test"}, {username: "test2", password_digest: "test2"} ] 当创建之间有间隔时它可以工作!和数组的打开,但是当没有间隙时,它给了我一个错误“参数数量错误(2 为 1)”。你知道为什么吗?
  • 我会用这个来更新我的答案,因为这里写得太长了;)
  • 酷。这有点复杂,需要了解 ruby​​ 在编写代码时如何试图弄清楚你的意思......
  • 这是一个很好的解释,现在我 100% 明白了 - 非常感谢您花时间教我 :)
猜你喜欢
  • 1970-01-01
  • 2017-07-14
  • 2020-05-23
  • 1970-01-01
  • 1970-01-01
  • 2015-03-10
  • 2011-07-25
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多