Создание миграции Rails из схемы

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

Есть ли способ генерировать миграции Rails с учетом SQL схемы?


person AaronThomson    schedule 01.04.2011    source источник
comment
должен признать, что нелегко найти дубликат: a-mysql-sql-file" title="можно ли сгенерировать файл миграции базы данных ruby ​​on rails из файла mysql sql">stackoverflow.com/questions/2754771/   -  person Spyros    schedule 01.04.2011
comment
Полностью согласен - это дубликат другого.   -  person François Beausoleil    schedule 01.04.2011
comment
Да, извините, это дубликат. Я искал, но не смог найти аналогичный ответ.   -  person AaronThomson    schedule 04.04.2011


Ответы (2)


Конечно, подключите приложение к базе данных, а затем запустите

rake db:schema:dump

Это даст вам готовый файл db/schema.rb со всеми вашими определениями. Теперь, когда у вас есть db/schema.rb, просто скопируйте содержимое объявления в новую миграцию. Я делал это раньше, и это работает просто отлично.

person François Beausoleil    schedule 01.04.2011

Я предпочитаю просто написать метод up начальной миграции с вызовами выполнения SQL:

class InitialDbStructure < ActiveRecord::Migration
    def up
        execute "CREATE TABLE abouts (
            id INTEGER UNSIGNED AUTO_INCREMENT,
            updated_at TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
            created_at TIMESTAMP,

            title VARCHAR(125),
            body MEDIUMTEXT,

            CONSTRAINT PK_id PRIMARY KEY (id),
            INDEX ORDER_id (id ASC)
            ) ENGINE=InnoDB;"
        end

ПРИМЕЧАНИЯ

  • Вы обнаружите, особенно если вы часто перестраиваете и заполняете таблицы (rake db:drop db:create db:schema:load db:fixtures:load), что операторы выполнения выполняются намного быстрее, чем интерпретируемый синтаксис Ruby. Например, нашим таблицам требуется более 55 секунд для перестроения из миграций Rails в синтаксисе Ruby, тогда как операторы execute повторно генерируют и повторно заполняют наши таблицы за 20 секунд. Это, конечно, существенная проблема в проектах, где исходное содержимое регулярно пересматривается или спецификации таблиц регулярно пересматриваются.

  • Возможно, что не менее важно, вы можете сохранить эту скорость перестроения и повторного заполнения, поддерживая одну исходную миграцию в исполняемом синтаксисе SQL и повторно выполняя миграции (этого единственного файла), сначала потрошив ваш schema.rb, а затем запуская rake db:reset перед повторным выполнением. -заполнение ваших таблиц. Убедитесь, что вы установили :version => 0, чтобы получить новую схему, верную вашей миграции:

    ActiveRecord::Schema.define(:version => 0) do  
    end
    
person mike montagne    schedule 09.09.2012
comment
Мне не нравится необработанный SQL при миграции, потому что ORM не может обернуть разные базы данных. Это медленнее, но вы покупаете портативность. Может быть, это не стоимость для всех потребностей - person New Alexandria; 05.04.2013
comment
Нет. На самом деле эта идея мешает необходимым упражнениям по использованию базы данных, которую вы выбрали из-за ее достоинств. Если вы намерены и нуждаетесь, например, в зависимости от типа Postgres BigSerial, вы должны взять быка за рога. Руби, конечно, намерен скрыть всю эту сложность, как если бы равнодушие и недоступность были добродетелями. Итак, нам помогли (наемные работники) скрыть наше преднамеренное использование типов данных, как будто они делают нам одолжение! - person mike montagne; 22.08.2013