Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 17
> Git не создаёт дополнительных каталогов со своими служебными файлами в каждой директории наблюдаемых структур. Так, например, поступает Subversion
Уже давно нет.
Уже давно нет.
orm-миграции для схемы данных + sql-файлы для вьюшек, функций и т.д. Пока такой подход устраивает
Не могли бы вы подробнее рассказать непосредственно о SQLFuse? У меня сразу возникло несколько вопросов:
- Каждому разработчику придется у себя локально разворачивать SQLFuse?
- Пока из описания я не понял как отслеживается переименование сущностей, например, таблиц. Вот я переименовал в файловой системе директорию, которая соответствует таблице. SQLFuse это как-то определит и сделает ALTER TABLE, попутно изменив все foreign key, которые ссылаются на эту таблицу?
- Как регулируются зависимости одних изменений от других? Вот допустим в одну таблице я добавил поле, а в другой сделай foreign key на это поле. Очевидно, что в неверной последовательности, изменения не накатятся
- Вы упомянули, что в случае неудачной попытки изменений «приводится в соответствие иерархия файлов и директорий с их фактическим состоянием относительно БД». Т.е. в так случае у нас получается «грязная» рабочая копия, в которой файлы не соответствуют текущей ревизии?
Да, конечно:
- Не обязательно. Можно, например, настроить Linux-сервер, подключаясь к которому (например по SSH), разработчики будут накатывать изменения на БД, либо же коммитить свои изменения при внесении изменений в структуру БД (например, через SSMS) вручную. Принцип тот же, что и с обычными файлами. Также, можно попробовать использовать SSHFS из Windows.
- Нет, SQLFuse не производит отслеживание зависимостей от foreign key и т.п., — это остаётся на совести разработчиков.
- При всех операциях, в рамках одного сброса кэша, ограничения создаются в последнюю очередь, и при удалении колонок с ограничениями, удаляются в первую очередь.
- Да, изменения пропадут, но можно же исправить ошибки и попробовать накатить заново?
- А на сервере для каждого разработчика заводить отдельные директории и базы с которыми они будут синхронизироваться? Это можно сделать только правкой конфига? Или с помощью SQLFuse можно и базы создавать?
- А как SQLFuse отслеживает сам факт переименования таблицы?
- Не могли вы тогда привести пример как с помощью SQLFuse добавляются и удаляются поля с констрейнтами?
- Т.е. я в момент разработки вношу изменения в файлы, их код выполняется с ошибкой и они бесследно исчезают?
- По-моему, самый оптимальный вариант — у каждого разработчика заводить отдельные директории потому, что меньше вероятности возникновения всевозможных коллизий, и у SQLFuse общий кэш для всех сделанных изменений. Можно, конечно, смонтировать БД в общий каталог и использовать SQLFuse для отслеживания изменений и создание коммитов только для истории, но в публикации хотелось рассмотреть вариант, когда изменения накатываются прямо из Git. С помощью описанного подхода можно достаточно быстро разворачивать необходимую структуру для каждого разработчиков. Абстракция здесь такая: одна БД отображается в одну директорию, поэтому, нет, нельзя создавать БД
- SQLFuse — это файловая система (на подобие SSHFS, FTPFS и др.), в которой отображаются модули SQL Server. Поэтому, при переименовании директории (которая может быть либо схемой, либо таблицей в абстракции SQLFuse), производится трансляция действия в выполнение процедуры sp_rename. Обратное же отслеживание, то есть из SQL Server, не ведётся, да и не возможно, по сути.
- Вы можете сами скачать базу AdventureWorks и потестировать это, проделав шаги, которые описаны в публикации :) Создайте последовательно соответствующие текстовые файлы в нужных директориях (таблицах), настроив заранее таймаут сброса кэша на время, достаточное, чтобы Вы успели это сделать
- Конечно же, сначала лучше внести изменения в репозиторий, допустим у себя на локальной машине, затем отправить его в центральный репозиторий, и уже оттуда подтянуть изменения в директорию, где примонтирована БД и настроен Git.
- Т.е. если разработчику понадобится еще одна база нужно будет править конфиг SQLFuse?
- Если в patch'е было переименование директории, git при апдейте с точки зрения ФС это делает именно переименованием?
- Вы писали, что «ограничения создаются в последнюю очередь», а как определяется в каких файлах содержатся ограничения? По префиксам файлов типа FK_* DF_*? И все равно не понятно как решается проблема очередности создания для остальных случаев, типа зависимости одной функции от другой.
- Т.е. вы предлагаете следущую схему разработки: правка кода -> коммит -> деплой на тест -> синтаксическая ошибка -> снова правка кода -> коммит и т.д. пока наши правки не заработают?
- Да, верно.
- Да, если произвести переименование в Git, будет выполнено именно переименование.
- Тип модулей определяется исходя из содержимого, например, ограничение DEFAULT выглядить как: CONSTRAINT DEFAULT (getdate()) FOR [dt_done]. SQL Server позволяет создавать функции, хранимые процедуры со ссылками на несуществующие пока объекты, однако, при выполнении, будет выдана ошибка, если они не были созданы.
- Синтаксические ошибки — это меньшее из зол, можно редактировать функции и процедуры в IDE, подключившись к серверу, чтобы избежать их -> делать коммит -> заливать на тест. Согласен, спорный момент, но для применения изменений нескольких процедур и полей вполне подойдёт. Но если изменения сложны, то, конечно, необходимо использовать скрипт напрямую в БД. А затем уже закоммитить в репозиторий.
Храним скрипты в git'е, написали утилиту, чтобы запускать только свежие для указанной БД скрипты.
SVN уже несколько лет как не хранит служебную информацию во всех подпапках.
Git не создаёт дополнительных каталогов со своими служебными файлами в каждой директории наблюдаемых структур. Так, например, поступает Subversion.
SVN уже несколько лет как не хранит служебную информацию во всех подпапках.
sql скрипты в git-репозитарии с древовидной структурой, понятной Flyway.
Если мы говорим о Microsoft SQL, то скорее всего разработка идёт в Visual Studio, а там есть тип проекта Database. Можно импортировать схему из существующей базы, редактировать, сравнить свой проект с существующей схемой, синхронизировать схемы. Естественно что это всё ложится в систему контроля версий. По-моему это более органичный путь.
картинка
Как это делаем мы описано тут: habrahabr.ru/post/258005
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Git и Microsoft SQL Server