Как стать автором
Обновить

Комментарии 17

> Git не создаёт дополнительных каталогов со своими служебными файлами в каждой директории наблюдаемых структур. Так, например, поступает Subversion

Уже давно нет.
Не могли бы вы подробнее рассказать непосредственно о SQLFuse? У меня сразу возникло несколько вопросов:
  1. Каждому разработчику придется у себя локально разворачивать SQLFuse?
  2. Пока из описания я не понял как отслеживается переименование сущностей, например, таблиц. Вот я переименовал в файловой системе директорию, которая соответствует таблице. SQLFuse это как-то определит и сделает ALTER TABLE, попутно изменив все foreign key, которые ссылаются на эту таблицу?
  3. Как регулируются зависимости одних изменений от других? Вот допустим в одну таблице я добавил поле, а в другой сделай foreign key на это поле. Очевидно, что в неверной последовательности, изменения не накатятся
  4. Вы упомянули, что в случае неудачной попытки изменений «приводится в соответствие иерархия файлов и директорий с их фактическим состоянием относительно БД». Т.е. в так случае у нас получается «грязная» рабочая копия, в которой файлы не соответствуют текущей ревизии?
Да, конечно:
  1. Не обязательно. Можно, например, настроить Linux-сервер, подключаясь к которому (например по SSH), разработчики будут накатывать изменения на БД, либо же коммитить свои изменения при внесении изменений в структуру БД (например, через SSMS) вручную. Принцип тот же, что и с обычными файлами. Также, можно попробовать использовать SSHFS из Windows.
  2. Нет, SQLFuse не производит отслеживание зависимостей от foreign key и т.п., — это остаётся на совести разработчиков.
  3. При всех операциях, в рамках одного сброса кэша, ограничения создаются в последнюю очередь, и при удалении колонок с ограничениями, удаляются в первую очередь.
  4. Да, изменения пропадут, но можно же исправить ошибки и попробовать накатить заново?
  1. А на сервере для каждого разработчика заводить отдельные директории и базы с которыми они будут синхронизироваться? Это можно сделать только правкой конфига? Или с помощью SQLFuse можно и базы создавать?
  2. А как SQLFuse отслеживает сам факт переименования таблицы?
  3. Не могли вы тогда привести пример как с помощью SQLFuse добавляются и удаляются поля с констрейнтами?
  4. Т.е. я в момент разработки вношу изменения в файлы, их код выполняется с ошибкой и они бесследно исчезают?
  1. По-моему, самый оптимальный вариант — у каждого разработчика заводить отдельные директории потому, что меньше вероятности возникновения всевозможных коллизий, и у SQLFuse общий кэш для всех сделанных изменений. Можно, конечно, смонтировать БД в общий каталог и использовать SQLFuse для отслеживания изменений и создание коммитов только для истории, но в публикации хотелось рассмотреть вариант, когда изменения накатываются прямо из Git. С помощью описанного подхода можно достаточно быстро разворачивать необходимую структуру для каждого разработчиков. Абстракция здесь такая: одна БД отображается в одну директорию, поэтому, нет, нельзя создавать БД
  2. SQLFuse — это файловая система (на подобие SSHFS, FTPFS и др.), в которой отображаются модули SQL Server. Поэтому, при переименовании директории (которая может быть либо схемой, либо таблицей в абстракции SQLFuse), производится трансляция действия в выполнение процедуры sp_rename. Обратное же отслеживание, то есть из SQL Server, не ведётся, да и не возможно, по сути.
  3. Вы можете сами скачать базу AdventureWorks и потестировать это, проделав шаги, которые описаны в публикации :) Создайте последовательно соответствующие текстовые файлы в нужных директориях (таблицах), настроив заранее таймаут сброса кэша на время, достаточное, чтобы Вы успели это сделать
  4. Конечно же, сначала лучше внести изменения в репозиторий, допустим у себя на локальной машине, затем отправить его в центральный репозиторий, и уже оттуда подтянуть изменения в директорию, где примонтирована БД и настроен Git.
  1. Т.е. если разработчику понадобится еще одна база нужно будет править конфиг SQLFuse?
  2. Если в patch'е было переименование директории, git при апдейте с точки зрения ФС это делает именно переименованием?
  3. Вы писали, что «ограничения создаются в последнюю очередь», а как определяется в каких файлах содержатся ограничения? По префиксам файлов типа FK_* DF_*? И все равно не понятно как решается проблема очередности создания для остальных случаев, типа зависимости одной функции от другой.
  4. Т.е. вы предлагаете следущую схему разработки: правка кода -> коммит -> деплой на тест -> синтаксическая ошибка -> снова правка кода -> коммит и т.д. пока наши правки не заработают?
  1. Да, верно.
  2. Да, если произвести переименование в Git, будет выполнено именно переименование.
  3. Тип модулей определяется исходя из содержимого, например, ограничение DEFAULT выглядить как: CONSTRAINT DEFAULT (getdate()) FOR [dt_done]. SQL Server позволяет создавать функции, хранимые процедуры со ссылками на несуществующие пока объекты, однако, при выполнении, будет выдана ошибка, если они не были созданы.
  4. Синтаксические ошибки — это меньшее из зол, можно редактировать функции и процедуры в IDE, подключившись к серверу, чтобы избежать их -> делать коммит -> заливать на тест. Согласен, спорный момент, но для применения изменений нескольких процедур и полей вполне подойдёт. Но если изменения сложны, то, конечно, необходимо использовать скрипт напрямую в БД. А затем уже закоммитить в репозиторий.
Храним скрипты в git'е, написали утилиту, чтобы запускать только свежие для указанной БД скрипты.

Git не создаёт дополнительных каталогов со своими служебными файлами в каждой директории наблюдаемых структур. Так, например, поступает Subversion.

SVN уже несколько лет как не хранит служебную информацию во всех подпапках.
Да? Видимо, я пробовал с очень старой версией. Тогда вообще замечательно, думаю, буду испытывать ещё раз, спасибо.
НЛО прилетело и опубликовало эту надпись здесь
Речь не идёт о том, какой софт хуже или лучше. Предложен ещё один способ решить проблему версионного контроля SQL-кода, не расходуя дополнительных ресурсов на приобретение специализированного ПО.
НЛО прилетело и опубликовало эту надпись здесь
Да, не знал об этой штуке. Спасибо, буду иметь ввиду. Идею SQLFuse можно использовать и для других СУБД, которую не поддерживает Database Project, осталость найти только энтузиастов :)
Если мы говорим о Microsoft SQL, то скорее всего разработка идёт в Visual Studio, а там есть тип проекта Database. Можно импортировать схему из существующей базы, редактировать, сравнить свой проект с существующей схемой, синхронизировать схемы. Естественно что это всё ложится в систему контроля версий. По-моему это более органичный путь.

картинка
image

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории