gpt4 book ai didi

ruby-on-rails - rails migration 在本地 Postgresql 上运行但在产品上失败

转载 作者:行者123 更新时间:2023-11-29 13:33:26 25 4
gpt4 key购买 nike

简而言之,在本地 Postgres 实例上删除、创建和运行 migrate 可以多次为我的应用程序创建工作数据库,但在 Heroku 的 prod 上使用相同的技术总是会产生:

heroku run rake db:migrate
Running `rake db:migrate` attached to terminal... up, run.9674
PG::UndefinedTable: ERROR: relation "mytable" does not exist
LINE 5: WHERE a.attrelid = '"mytable"'::regclass
^
: SELECT a.attname, format_type(a.atttypid, a.atttypmod),
pg_get_expr(d.adbin, d.adrelid), a.attnotnull, a.atttypid, a.atttypmod
FROM pg_attribute a LEFT JOIN pg_attrdef d
ON a.attrelid = d.adrelid AND a.attnum = d.adnum
WHERE a.attrelid = '"mytable"'::regclass
AND a.attnum > 0 AND NOT a.attisdropped
ORDER BY a.attnum

rake aborted!
PG::UndefinedTable: ERROR: relation "mytable" does not exist
LINE 5: WHERE a.attrelid = '"mytable"'::regclass
^
: SELECT a.attname, format_type(a.atttypid, a.atttypmod),
pg_get_expr(d.adbin, d.adrelid), a.attnotnull, a.atttypid, a.atttypmod
FROM pg_attribute a LEFT JOIN pg_attrdef d
ON a.attrelid = d.adrelid AND a.attnum = d.adnum
WHERE a.attrelid = '"mytable"'::regclass
AND a.attnum > 0 AND NOT a.attisdropped
ORDER BY a.attnum

编辑:请参阅问题底部以获取有关在迁移期间访问 Controller 的线索。

这是在本地工作的:

rake db:drop
rake db:create
rake db:migrate

我有

  • 通过执行 heroku pg:psql 确认 Heroku 的数据库在迁移之前是空白的,然后 \dt 验证是否存在 0 个表。
  • 在迁移之前尝试了 heroku pg:reset DATABASE
  • 确认本地和 prod Postgres 都是版本 9.2.4
  • 尝试将 db/migrate 中的“mytable”迁移文件重命名为具有最早的时间戳,以便首先运行

这是一个非常简单的应用程序,因此非常令人沮丧的是,像从头开始创建数据库这样的基本操作总是失败。有什么想法吗?

“我的表”迁移:

class CreateMytable < ActiveRecord::Migration
def change
create_table :mytable do |t|
t.string :codes
t.string :name

t.timestamps
end
end
end

可能引用迁移:

class CreateTable2 < ActiveRecord::Migration
def change
create_table :table2 do |t|
t.references :a, index: true
t.references :b, index: true
t.string :c
t.string :d

t.timestamps
end
end
end

编辑:在使用 --trace 运行 db:migrate 时注意到一条线索。下面错误的堆栈跟踪顶部显示 Controller 错误?为什么 Controller 会参与迁移?

/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.0/lib/active_record/connection_adapters/postgresql_adapter.rb:768:in `exec'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.0/lib/active_record/connection_adapters/postgresql_adapter.rb:768:in `exec_no_cache'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.0/lib/active_record/connection_adapters/postgresql/database_statements.rb:138:in `block in exec_query'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.0/lib/active_record/connection_adapters/abstract_adapter.rb:425:in `block in log'
/app/vendor/bundle/ruby/2.0.0/gems/activesupport-4.0.0/lib/active_support/notifications/instrumenter.rb:20:in `instrument'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.0/lib/active_record/connection_adapters/abstract_adapter.rb:420:in `log'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.0/lib/active_record/connection_adapters/postgresql/database_statements.rb:137:in `exec_query'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.0/lib/active_record/connection_adapters/postgresql_adapter.rb:915:in `column_definitions'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.0/lib/active_record/connection_adapters/postgresql/schema_statements.rb:174:in `columns'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.0/lib/active_record/connection_adapters/schema_cache.rb:114:in `block in prepare_default_proc'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.0/lib/active_record/connection_adapters/schema_cache.rb:56:in `yield'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.0/lib/active_record/connection_adapters/schema_cache.rb:56:in `columns'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.0/lib/active_record/model_schema.rb:208:in `columns'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.0/lib/active_record/model_schema.rb:242:in `column_defaults'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.0/lib/active_record/locking/optimistic.rb:169:in `column_defaults'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.0/lib/active_record/core.rb:181:in `initialize'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.0/lib/active_record/inheritance.rb:27:in `new'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.0/lib/active_record/inheritance.rb:27:in `new'
/app/app/controllers/home_controller.rb:7:in `<class:HomeController>'

有问题的第 7 行包含对 Mytable.new(... 的调用。 Controller 代码如何在 db:migrate 期间进入作用域?

最佳答案

这是由于在 Rails Controller 中设置了一个引用“mytable”类的类变量造成的。所以基本上是这样的:

 class HomeController < ApplicationController
@@data = {MyTable.new(...

将 this 移到 Controller 方法中并使其成为非类变量解决了问题(我没有区分是类 var 方面还是类 def 正下方的位置是原因)。

我仍然不明白为什么 Controller 代码是数据库迁移的一个因素。我很想知道这是我做错了什么,还是 rake 、 rails 或其他东西中的错误。只发生在 Heroku 生产中,Rails 4.0.0

关于ruby-on-rails - rails migration 在本地 Postgresql 上运行但在产品上失败,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/18678817/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com