Что такое db / development_structure.sql в проекте rails?

В папке my / db моего приложения rails есть файл development_structure.sql (rails 2.3.4, ruby ​​1.8.7), и я не совсем уверен, что именно он делает.

  1. Нужно ли это для какой-то конкретной среды? (Кажется, я где-то читал, что он используется для тестов)
  2. Нужно ли добавлять его в мой репозиторий git?
13.10.2009 13:09:07
это то же самое, что структура.sql в рельсах 3? Если это так, этот вопрос следует отредактировать
boulder_ruby 20.08.2012 23:48:14
4 ОТВЕТА
РЕШЕНИЕ

Вы не должны добавлять его в свой репозиторий git.

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

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

config.active_record.schema_format = :sql

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

rake db:test:clone_structure

редактировать

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

Они рекомендуют проверить это в системе контроля версий в вики.

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

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

22
9.03.2013 15:09:05
... за исключением того, что вы должны добавить его в свой репозиторий, точно так же, как вы должны добавить schema.rb в свой репозиторий. Смысл наличия файла в хранилище состоит в том, что вам не нужно запускать все миграции при настройке новой БД.
Marnen Laibow-Koser 7.05.2012 15:12:02
@ MarnenLaibow-Koser У меня это есть в репо, и оно всегда меняет значение идентификаторов auto_increment, что довольно раздражает
ecoologic 27.02.2013 01:04:03
@ecoologic Да, это может быть немного раздражающим. Это одна из причин, по которой вы должны использовать schema.rb вместо struct.sql, если это вообще возможно. Но это обязательно должно быть в хранилище.
Marnen Laibow-Koser 6.03.2013 22:54:53
да, я люблю схему гораздо лучше, она также является хорошим справочником по существующим полям,
ecoologic 7.03.2013 00:00:26
Миграция плохо работает на Heroku. Например, Heroku не запускает миграцию, скопированную с движка. Он запускает только те, что в приложении. Также на Heroku невозможно ввести COPYкоманду PG в миграцию. Эта миграция и все остальные миграции после нее будут прерваны. Heroku очень тяжело завершает создание БД, когда процесс миграции нарушен. Я обнаружил, что миграция Rails хорошо работает только на localhost, но они слабы в развертывании. По крайней мере, на Heroku.
Green 19.06.2013 05:53:19

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

1
13.10.2009 13:42:52

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

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

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

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

Короче говоря, имея доступную структуру схемы, каждый раз, когда вы меняете ветку / коммит, вы загружаете ее напрямую и забываете об этом. Это в основном справедливо для динамических и «переполненных» проектов, где разные ветви имеют различия в базовой структуре схемы.

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

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

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

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

30
4.03.2014 16:19:03

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

config.active_record.schema_format =: sql

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

0
19.10.2012 07:32:58