使用 STI 迁移数据库失败

Using STI fails to migrate database

处理这个问题已经有一段时间了,觉得是时候寻求帮助了。我查看了以下链接,但没有成功

PG undefinedtable error relation users does not exist

https://github.com/rails/rails/issues/3279

我的问题与此https://github.com/rails/rails/issues/6470有些相似,但不完全相同。

我有一个名为 type_tables 的 class,它是 STI 的基础 class 这里是 STI

的架构
create_table "type_tables", force: :cascade do |t|
 t.string "title"
 t.string "desc"
 t.string "type"
 t.string "uom"
 t.index ["title"], name: "index_type_tables_on_title"
 t.index ["type"], name: "index_type_tables_on_type"
end

现在,这个类型table在我的项目中只是一个基础class,其他类型如device_type、certificate_type等继承自它。

type_table

的模型
class TypeTable < ApplicationRecord
  validates :title, presence: true, uniqueness: true
end

另一个device_type型号

class DeviceType < TypeTable
  has_many :certificates
  #this is where the error originates
  GARMIN_ID = find_by(title: "Garmin").id

  #when i use some constant value rails successfully executes the 
   db:create task in my rake file
  GARMIN_ID = 22

end

现在,有趣的是,它仅在第一次显示此行为,即当我的 Postgres 数据库中不存在 table 时。当我成功创建和迁移我的应用程序架构并且存在 table 时,此行将每次都有效。

GARMIN_ID = find_by(title: "Garmin").id

我的想法是,由于它试图在 type_tables 关系中查找列,但该关系不存在,因此它会抛出一个没有关系存在的错误。虽然您在控制台上看到的错误是

2018-08-07 02:24:49.281 UTC [69] FATAL:  database "myappdb" does not 
exist

mlcot_api | /usr/local/bundle/gems/activerecord-5.1.3/lib/active_record/connection_adapters/postgresql_adapter.rb:699:in 
`rescue in connect': FATAL:  database "myappdb" does not exist 
(ActiveRecord::NoDatabaseError)

当我使用

手动创建数据库时
docker-compose run api rake db:create

然后运行 docker-合成我得到

ERROR:  relation "type_tables" does not exist at character 566

/usr/local/bundle/gems/activerecord- `async_exec': PG::UndefinedTable: 
ERROR:  relation "type_tables" does not exist 
           (ActiveRecord::StatementInvalid)
           WHERE a.attrelid = '"type_tables"'::regclass

注意:我知道解决方法并且我的应用程序可以正常工作,但我依赖于一个特定的分支,该分支包含所有注释代码 需要第一次构建我的数据库,我想删除它。

感谢任何帮助并提前致谢。

在加载模型定义时访问数据库是一个非常糟糕的主意。不要那样做。

相反,请考虑使用仅在第一次需要时检索值的 class 方法:

def self.garmin_id
  @garmin_id ||= find_by(title: "Garmin").id
end

就我个人而言,即使是那么多的持久性我也强烈反对——最好花一个查询为每个需要它的请求重新检索它——但这更多是设计判断的问题。