Я новичок в рельсах и стараюсь понять взаимосвязь между миграциями и моделями. Насколько я могу утверждать, что миграция влияет только на хранилище данных после того, как я использую строительные леса для создания ресурса, я тогда отвечаю за синхронизацию модели и миграции? Есть ли какие-нибудь инструменты для этого?Почему миграция не обновляет модель?
Извините, если это очевидный вопрос, я все еще работаю над документами.
Все миграции - это изменение базы данных. Rails обрабатывает синхронизацию между моделью и базой данных.
Вы можете иметь User таблицу, которая имеет id, firs_name и модель класса может выглядеть следующим образом
class User < ActiveRecord::Base
end
Как вы можете видеть класс модели пуст, и вы можете все еще довольно много методов доступа по этому классу например:
@user = User.new
@user.first_name = "Leo"
@user.save!
и он будет знать, что с ним делать.
Миграции - это всего лишь файлы, которые позволяют вам изменять базу данных поэтапно, сохраняя правильное управление версиями в схеме базы данных.
Конечно, Rails будет жаловаться, если вы попытаетесь вызвать вещи из вашей модели, которых нет в базе данных, или родительский класс ActiveRecord::Base.
@user = User.new
@user.awesome
#=> undefined method `awesome` for #<User:some_object_id>
Что касается миграций, вы можете иметь несколько миграций, которые влияют на одну таблицу. Ваша задача - узнать только, какие атрибуты вы добавили в модель. Rails сделает все остальное за вас.
Итак, чтобы проверить, что я понимаю, модель класса никогда не будет содержать информацию о полях, определенных с помощью миграций, а основным источником информации о схеме является schema.rb, а не файлы модели? –
Думаю, в некотором роде. Схема - это просто представление того, что было записано в базу данных до сих пор миграциями. Его в простом рубине или вы можете выводить его как SQL. На самом деле взаимодействие между моделью и базой данных - это ActiveRecord :: Base. В частности, если вы выполняете 'SomeModel.new.method (: some_method) .source_location', он указывает на то, где метод определен и интересно, он указывает на' lib/active_record/attribute_methods/read.rb' –
Общее правило заключается в том, что миграции лучше всего подходят для определения данных - столбцы в таблице, их тип, ограничения и т. Д. Таким образом, нет необходимости синхронизировать миграцию с вашими данными.
Если в конечном итоге само определение данных изменяется (новый столбец или изменение типа столбца), то просто добавьте новую миграцию, указав то же самое.
Модели ActiveRecord управляются, в общем, из базы данных. Любые поля, определенные в базе данных, будут (как правило) автоматически отображаться как свойства в модели activerecord, привязанные к этой таблице.
Изменение модели не изменит схему (как правило). Чтобы изменить модель, обычно можно определить перенос и запустить ее в базу данных.
Обратите внимание: ничто не останавливает вас при определении дополнительных свойств модели с помощью attr_accessor и т. Д., Но они не будут сохраняться ActiveRecord, если в схеме, к которой они привязаны, нет столбца.
Я принял ответ Лео, так как он помог мне понять вещи лучше, и если бы я только что получил в нижней части страницы миграций я бы необходимо, чтобы не спросить: http://guides.rubyonrails.org/migrations.html#what-are-schema-files-for
Упомянутая annotate_models камень также полезный для повышения осведомленности о текущей структуре модели класса без необходимости ссылаться на схему.
Если вы хотите восстановить поведение attr_accessor и вместо того, чтобы дать белый список дают черный список, вы можете сделать на модели с помощью этого:
attr_accesible *atribute_names - %(attributes black list)
Что вы имеете в виду 'модели и миграции в sync'? Вы должны добавить новую миграцию и начать использовать новые атрибуты на своей модели, а не продолжать редактирование существующей миграции (ну, иногда, но хорошо ...) – fotanus
Мое замешательство частично связано с тем, что использование эшафота для генерации ресурс добавляет attr_accessible к модели. Я был удивлен, что создание переноса для добавления нового поля не обновляло модель. –
'attr_accessible' - это белый список массовых заданий. Представьте себе, если Rails автоматически обновит это для вас, когда вы добавили что-то вроде 'admin' в схему! – mikeryz