Как создать JoinTable с id типа не Integer?

Question

Используя генераторы я создал 2 модели (и таблицы в БД):

rails g model Article name:string hunt_name:string body:text

rails g model Category name:string hunt_name:string

После чего в моделях я прописал следующее:

class Category < ApplicationRecord
  self.primary_key = :hunt_name
  has_and_belongs_to_many :articles
end


class Article < ApplicationRecord
  self.primary_key = :hunt_name
  has_and_belongs_to_many :categories
end

Насколько я понимаю, primary_key указывает поле, по которому будет производиться поиск при вызове, например Article.find(id) (поправьте, если неправ). Кроме того в поле id данной таблицы будет содержаться уже не число (1, 2, 3...), а именно то, что находится в поле hunt_name (опять же, поправьте, если неправ).

После этих манипуляций я создал JoinTable:

rails g migration CreateJoinTableArticlesCategories articles categories

Но привязки статей к категориям не происходит по очевидной причине (узнал, посмотрев в скиму): поля в Join Table'е имеют тип integer, в то время как hunt_name, который, как мне кажется (см. выше) является id в своей таблице - типа string.

Отсюда вопрос: стоит ли вообще делать так, как я делаю (может быть стоит вообще отключить id в таблицах articles и categories)? Если это не противоречит Convention over Configuration, то как указать Join Table'у, что его поля должны иметь тип string? Или по-другому: как сохранить id в двух таблицах в числовом виде, но при этом оперировать данными, обращаясь к hunt_name (как будто бы это он id), и при этом всем не менять тип данных в Join Table'е? Что из этого лучше и как делать правильнее?

Answer 1

Ох, с чего бы начать...

self.primary_key = :hunt_name

Выкиньте это вообще и впредь не трогайте руками свойство primary_key.

Что является первичным ключом в таблице, указывается в самой таблице, прямо в БД, при её создании. То, что вы ORM даёте такую "вредную подсказку", расходящуюся со схемой БД, может привести к совершенно непредсказуемым последствиям.

---

Rails довольно навязчиво предлагает использовать т. н. "суррогатный первичный ключ", который заключается в искуственном сопоставлении каждой записи какого-то уникального и всегда существующего значения. Обычно реализуется автоинкрементом, реже случайными UUID, а бывает и иначе.

Вы же предполагаете, что в вашем случае строковый hunt_name тоже сгодится как первичный ключ. Может и так, я вашей предметной области не знаю, если это из неё следует, то это "натуральный первичный ключ". По меньшей мере убедитесь, что значения этого свойства сущности (= столбца таблицы) удовлетворяют следующему:

• Они уникальны среди всех записей (UNIQUE constraint)
• Они есть у каждой записи (NOT NULL constraint)

А ещё хорошо бы, чтобы они никогда не менялись, потому что первичный ключ таблицы указывает на канонический способ ссылаться на отдельные строки этой таблицы, т. е. значения этого ключа будут не только в самой таблице, но и во всём, что на неё ссылается. Если менять их, то везде. Если у вас в БД ещё при этом хорошо настроена поддержка ссылочной целостности (наложены строгие внешние ключи везде, где они правда есть), то БД вам ещё будет постоянно жаловаться, что изменяя значение первичного ключа вы нарушаете ссылочную целостность. Где-то можно временно ослабить требования (проверять целостность только при коммите), но не везде.

Сделать таблицу, которая имеет строковый первичный ключ можно такой миграцией:

create_table :things, id: false do |t|
  t.primary_key :key, :string
end

Если вам потребуются составные первичные ключи (например), ActiveRecord вообще расползётся по швам. Возьмите Sequel, к примеру.

Оставлять же модель без первичного ключа вовсе плохая идея, т. к. ActiveRecord не сможет с объектами такой модели делать практически ничего, кроме чтения/инстанцирования.

---

А что касается соединительных таблиц — как можно было заключить из вышенаписанного, традиционно они содержат первичные ключи связываемых таблиц, но при этом собственного первичного ключа не имеют. Написать определение такой таблицы в миграции можно и самостоятельно, необязательно безвольно слушаться рельсогенератора. Избавиться от оков has_and_belongs_to_many можно, перейдя на has_many :through (рекомендуется) или с помощью опций.