Rails/Ruby Как переопределить временные метки метода миграции

Я пытаюсь написать свой собственный метод временных меток, который запускается во время миграции. Тот, который сейчас есть, добавляет к полю ограничение NOT_NULL, а я действительно этого не хочу.

У меня проблема в том, что у меня есть база данных с несколькими схемами. Где каждый крупный клиент получает свою собственную схему. Когда мы подключаем нового клиента, мы создаем новую запись арендатора, а затем запускаем миграцию для новой схемы.

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

Последняя миграция, которую я выполнил, использовала более старую версию рельсов. Все еще в 3-х, но чуть старше. Когда он создал временные метки, они были равны NULL. Когда я на днях запустил миграцию (на новых рельсах)... Ну, все поля теперь NOT_NULL

У меня есть код, который был разработан с идеей, что updated_at заполняется только при обновлении записи... а не при ее создании. (сторонние приложения и "функции" базы данных создают записи). Сторонние приложения и функции базы данных, которые создают записи, падают на новую схему... Я вошел и удалил все ограничения NOT_NULL для всех таблиц. вручную, но я не хочу писать очистку прямо в мою задачу миграции, чтобы все будущие таблицы были исправлены.

Я решил, что лучше всего будет переопределить метод временных меток, который был изменен, и вернуться к тому, который не нарушал существующий код.

Итак, есть причина, по которой мне нужно отменить/переопределить..
Теперь у меня вопрос... Как мне переопределить метод. Я не вижу к нему четкого пути к классу, и я не совсем уверен, как его переопределить.


ruby-on-rails timestamp overriding classpath
person baash05    schedule 22.03.2013    source источник

Ответы (2)


arrow_upward
4
arrow_downward

Поместите это в патч для обезьян... Проще всего!

class ActiveRecord::ConnectionAdapters::PostgreSQLAdapter::TableDefinition
  def timestamps(*args)
    options = args.extract_options!
    column(:created_at, :datetime, options)
    column(:updated_at, :datetime, options)
  end
end

Как сказал Манек. Обновления рельсов будут игнорироваться из-за этого «исправления».

Но его первоначальное предложение делает то же самое. Кроме того, чтобы приспособиться к его исправлению, вам нужно вернуться к старым миграциям и заменить «временные метки» новым кодом. Добавьте к этому, что вам также придется заменить все будущие автоматически сгенерированные миграции.

Я не думаю, что это хорошо подходит для DRY. И не подходит для SPOT.

Просто Б осторожно!

person baash05    schedule 25.03.2013

arrow_upward
1
arrow_downward

Что случилось с:

create_table :foo do |t|
   t.text :bar
   t.datetime :created_at
   t.datetime :updated_at
end

?

person maniek    schedule 24.03.2013
comment
У меня уже есть более 50 миграций, я не хочу перебирать их, меняя их все на эту парадигму. Я также не хочу менять код в rails create scaffold, чтобы он вставлял сломанную дату и время вместо временных меток. - person baash05; 25.03.2013
comment
@daveatflow изменение миграций, безусловно, займет у вас меньше времени, чем написание вопроса :) Что касается того, где переопределить: можно ли запускать задачи rake с включенной отладкой? поместите вызов debugger внутри блока create_table, войдите в метод timestamps, вы должны получить местоположение файла. Я лично не рекомендую это, так как это также может измениться в будущих версиях рельсов. - person maniek; 25.03.2013
comment
Ну, как я уже сказал, у меня более 50 миграций, мне придется изменить их все, и все будущие миграции генерируются рельсами. Я также должен был бы задокументировать, что другим пришлось изменить созданные рельсы миграции. Логика отладчика... вот это умно. К изменению в будущих версиях. Я специально пытаюсь этого избежать. Если они меняют имена полей (например), то у меня одна база данных, две схемы, которые должны быть одинаковыми, но иметь разные имена полей. - person baash05; 25.03.2013
comment
@daveatflow Под изменением в будущей версии рельсов я имел в виду, что они могут, например, решить перенести логику в класс Bar, пока вы все еще исправляете Foo. - person maniek; 25.03.2013
comment
Дай бог, я буду программировать на Java задолго до того, как это произойдет. - person baash05; 26.03.2013