Какова высокоуровневая взаимосвязь ActiveRecord и миграций в rails?

Question

[Promix17]

Делаю проект, где используется ActiveRecord и миграции без rails. Идеи взяты отсюда:

habrahabr.ru/post/98751
blog.aizatto.com/2007/05/21/activerecord-without-rails
blog.aizatto.com/2007/05/27/activerecord-migration...

Захотелось генерировать файлы автоматически, как в rails - не нашёл решения и породил следующий костыль:

https://rubygems.org/gems/rails_tools.

Но вот в чём суть - я не понимаю философии связи ActiveRecord, миграции и высокоуровневой сущности модели. Почему после команды rails g model теряется описание модели? Почему я должен вручную добавлять операторы has_many в производные класса ActiveRecord::Base? Есть ли средство, чтобы описать модель на каком-нибудь DSL, а потом генерировать производные класса ActiveRecord::Base и миграции автоматически? Почему был выбран именно такой механизм порождения сущностей через консоль, а не конфиг на DSL? Я ведь даже не могу определить структуру конкретного элемента ActiveRecord без обращения к файлу миграции.

Comments

[Дмитрий Полушкин]

Попробуйте ODM: MongoID или DataMapper. Вроде то, о чём вы пишите, как раз воплощено именно там.

[Promix17]

DataMapper, видимо, то, что нужно.

Answer 1

[Promix17]

Не очень понял про последующие изменения. Если сделать как я предлагаю, то при изменении нужно будет всего лишь изменить один главный файл описания модели на DSL и сделать автоматическую генерацию файлов миграции и модели в одну команду. При этом должны автоматически создаться файлы миграций для обновления существующей версии БД: например, добавилось поле (разрешается автоматически), поле было переименовано (спросить у пользователя в консоли) и т.д.

Comments

[thepry]

OnYourLips: А если я в рельсах захочу для user вместо колонки name использовать username, при этом не переписывать все упоминания user.name на user.username ?

[Promix17]

Суть в том, что модель и бизнес-логика связаны, нарушается принцип DRY