Что такое db/development_structure.sql в проекте рельсов?

Ответ 1

Нельзя добавлять его в репозиторий git.

Это файл, созданный автоматически рельсами при запуске миграции с помощью вашей базы данных, настроенной для подключения к базе данных mysql. Вы можете просмотреть его в качестве альтернативы schema.rb

Я считаю, что вы можете заставить рельсы создать его, добавив в свою среду .rb:

config.active_record.schema_format = :sql

При наличии этого файла используется, например,:

rake db:test:clone_structure

Edit

Соответствующий раздел в руководствах Ruby On Rails. http://guides.rubyonrails.org/migrations.html#schema-dumping-and-you

Они рекомендуют проверить его в исходном коде на вики.

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

Однако, похоже, сейчас это вопрос личного вкуса. Следуйте своим инстинктам на этом.

Ответ 2

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

development_structure.sql - это низкоуровневый дамп схемы, который необходим, когда вы начинаете использовать собственные функции базы данных - либо вы хотите, либо не хотите, вы собираетесь использовать их в какой-то момент.

Что касается вопроса о его хранении или нет, есть некоторые дебаты. Вот информативный пост: http://www.saturnflyer.com/blog/jim/2010/09/14/always-check-in-schema-rb/. И мое взятие на это следует.

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

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

Без сохранения структуры схемы вам всегда нужно использовать существующую ссылочную схему в своей базе данных и перенести ее обратно или переадресовать каждый раз, когда вы меняете ветвь/фиксацию; несколько случаев в реальном мире могут сделать этот процесс неэффективным (например, когда другая ветвь не имеет некоторых миграций, которые у вас есть в настоящее время, или некоторые миграции не могут быть отброшены назад).

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

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

Я не говорю, что вы не можете жить без development_structure.sql - конечно, можете. Но если у вас есть это, при изменении ветки/фиксации вы просто загружаете и забываете; если вы этого не сделаете, вам [может] придется пройти ряд ручных шагов.

Ответ 3

Он создается, когда вы запускаете команду rake, чтобы клонировать вашу базу данных разработки в тестовую базу данных. База данных разработки выводится на SQL, который затем считывается в тестовую БД. Вы можете безопасно удалить его.

Ответ 4

В рельсах 3 вам даже не нужно писать эту строку,

config.active_record.schema_format =: sql

Вы можете сгенерировать этот файл structure.sql, просто выполнив вышеупомянутую команду rake, упомянутую выше