я больше склоняюсь к AR подходу

^

просто это может от тебя не зависеть)

я о том, что там написано на AR скорее всего, а не о том что я хочу)

ну то есть смотри, если например все изменения идут через приложение, то можно играться с моделью Author: делать "фейковые" колонки, перенаправлять и всякое такое

но если какая-то сторонняя (по отношению к приложению) интеграция лезет напрямую в базу, то надо это решать на другом уровне тогда

ну в смысле вдруг у вас там есть микросервис на го, который тоже читает и пишет в эту базу

Спасибо, приму к сведенью)

да, так вот. если всё через приложение, то сделать можно вот как

class Author
  def email_address
    email_addresses.last&.value
  end

  def email_address=(value)
    email_addresses.find_by(value: email_address)&.mark_for_destruction
    email_addresses.new(value: value)
  end
end

если есть сторонний доступ напрямую к базе, но он только на чтение, то можно сделать вот так

class Author
  after_update :sync_email

  private
  
  def sync_email
    email_address_changed? or return

    email_addresses.find_by(value: email_address_was).destroy
    email_addresses.create(value: email_address)
  end
end

но тогда такой же синхронизатор надо бы сделать и на стороне модели Email, если они могут меняться

если же есть сторонний доступ и на чтение и на запись, то это можно решить только на уровне самой базы - триггеры и все такое

сохраню в закладки, пожалуй).

спасибо вам большое. Вы не первый раз мне помогаете)

пожалста)

Ещё в транзакции это дело обернуть, чтоб рассинхрона не было

так after_update до закрытия транзакции срабатывает

Ээээ да ладно

ну да, есть же отдельный after_commit

Надо будет чекнуть

другое дело, что колбеки - говно, но тут уже ничо не поделаешь

А почему так?

emal_changed? or return

а почему нет?