SQL.RU
 client/server technologies
 Главная | Документация | Статьи | Книги | Форум | Блоги | Опросы | Гостевая | Рассылка | Работа | Поиск | FAQ |

Управление исходным кодом

ПУБЛИКАЦИИ  

Глава из книги Кена Хендерсона: Профессиональное руководство по SQL Server: хранимые процедуры, XML, HTML (+CD)
Авторы рассылки благодарят издательский дом ПИТЕР за предоставленные к публикации материалы.

Аннотация издательства

Книга посвящена философии программирования в Transact-SQL. Она объясняет, как применять эту философию для создания собственных способов кодирования и решения повседневных проблем. В ней, помимо основной темы, — хранимых процедур, — раскрыто множество вспомогательных, среди которых XML, HTML, .NET. Причина этого проста: когда вы создаете реальное программное обеспечение, вам всегда приходится работать с несколькими технологиями. Эта книга признает данный факт, раскрывая многие сопутствующие технологии и рассматривая их с точки зрения разработки хранимых процедур для SQL сервера. Книга рассчитана на разработчиков среднего и высокого уровня, которые хотят совершенствоваться в программировании хранимых процедур

СОДЕРЖАНИЕ

Введение

Я не выдающийся программист - я программист с вы­дающимися привычками.
К. Бек

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

Среди разработчиков Transact-SQL, особенно неопытных, распространено такое обращение с кодом Transact‑SQL, как будто бы это "ненастоящий" код. Они не пользуются подходящим редактором и вполне удовлетворены, работая по восемь часов в день со средствами, предназначенными скорее для редактирования командных файлов, а не программного кода. Они не комментируют свой код и не следуют никаким правилам, которые можно увидеть в языках программирования других типов. Для управления своим кодом на Transact‑SQL они не пользуются средствами управления исходным программным кодом (системами контроля версий), такими как: VSS, PVCS, Source Integrity (Vertical Sky Software Manager).

Напротив, код хранимых процедур рассматривается скорее как ресурс базы данных, нежели как программный код и, исходя из этого, управляется в атомарной, транзакционной манере, которая обычно применяется к другим типам объектов базы данных. В этой перспективе код процедур на Transact-SQL - просто данные. Более того, код хранимых процедур располагается в базе данных в таблице syscomments и защищен от повреждения, как и другие данные, посредством резервного копирования - такова логика рассуждений.

Цель этой главы - развеять миф, что код Transact-SQL является "ненастоящим" кодом, и показать важность управления исходными текстами (то есть управления версиями) с помощью специального программного обеспечения. Хотя вы можете использовать любую систему для управления версиями текстовых файлов, в этой главе будет рассказано о VSS, поскольку я использую это средство.

[В начало]

Преимущества управления исходными текстами

Полагаю, что обсуждение следует начать с разговора о преимуществах хранения вашего кода на Transact‑SQL в системах контроля версий. Не все из этих преимуществ очевидны сразу, поэтому их будет полезно перечислить и пояснить.

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

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

В-третьих, системы контроля версий гарантируют согласованность версий. Когда вы разрабатываете и выпускаете программное обеспечение, со временем, естественно, начинают появляться новые версии. И, скажем, через шесть месяцев после выпуска очередной версии продукта вам понадобится снова скомпилировать "ту самую" версию. Система контроля версий позволяет присвоить метки и получить всю версию целиком за один шаг при нажатии кнопки. Вы просто находите версию с необходимой меткой и даете системе команду восстановить ее для вас. Подумайте, каким бы сложным оказался этот процесс без помощи такой системы контроля. Найдя файлы требуемой, как вам кажется, версии, вы должны были бы проверить каждый файл - сотни или даже тысячи файлов - и убедиться, что они не только соответствуют требуемой версии приложения, но также имеют одинаковую версию. И это подразумевает, что вы прежде всего сохраняете исходный код старой версии. В сущности, вы были бы вынуждены сами исполнять роль системы контроля версий. Вместо создания программного обеспечения, вы бы проводили изрядное количество времени, занимаясь вещами, которые лучше поручить компьютеру.

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

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

ПРИМЕЧАНИЕ

Я пишу об этом несмотря на то, что на горизонте новое поколение систем контроля версий, которое серьезно изменяет тенденции развития этих систем. Управление изменениями и другие операции по управлению программным кодом в этих новых системах скорее ориентированы на большие команды разработчиков. Например, существует широко разрекламированная возможность одновременного изменения одного файла с исходным текстом несколькими разработчиками. При этом система контроля версий выполняет трехсторонний (или "многосторонний") контроль различий и разрешает конфликты между разными версиями одного и того же члена команды. Очевидно, это может быть большим преимуществом для больших команд с большими файлами программного кода. Традиционные системы контроля версий предотвращают изменения файла с кодом - даже независимые и несвязанные изменения - до тех пор, пока кто‑либо не пометит файл. В больших командах разработчиков нередко случается, что кто-то один просит другого сделать регистрацию изменений файла для того, чтобы он мог продолжить свою работу. Как я сказал, эта глава рассматривает контроль версий в перспективе использования более традиционных средств, вроде VSS, но не стоит забывать о существовании средств нового поколения.

[В начало]

Процедуры dt

Если после установки Visual Studio Enterprise вы долго бродили по системным таблицам на вашем сервере, возможно, вы заметили встроенные Microsoft хранимые процедуры, чьи имена начинаются на dt. Эти процедуры используются Visual Studio для обеспечения управления исходными текстами хранимых процедур на Transact-SQL. Беглый просмотр этих процедур показывает, что они используют COM-объект SQLVersionControl.VCS_SQL. Этот объект используется Visual InterDev для управления кодом хранимых процедур прямо из среды разработки (IDE). Если вы установили серверные компоненты (Visual InterDev Server Components), в вашей системе уже установлен этот объект, и вы вполне можете использовать процедуры dt_% прямо из InterDev.

Поскольку не у всех установлена версия Visual Studio Enterprise, в этой главе будет показано, как управлять сценариями Transact-SQL, используя среду VSS и поставляемый VSS COM-интерфейс.

[В начало]

Удачные решения

Поскольку контроль версий относится к сфере управления, имеет смысл начать обсуждение с того, что в кругах менеджеров известно под названием удачные решения. Удачные решения - это лучшие технические приемы и методики решения каких-либо задач. Все области - особенно инженерные - имеют лучшие решения; в большинстве сфер квалифицированного труда существуют подходы, которые работают лучше других. Я расскажу о нескольких подходах, заслуживающих того, чтобы их использовали в области контроля версий.

[В начало]

Храните объекты в сценариях

Возможно, вы и правы, храня программный код Transact-SQL создаваемых объектов исключительно в базе данных SQL Server, которой принадлежат объекты, но мне кажется, это не очень хорошая идея. Почему? Потому что без средств, вроде процедур dt_%, вы лишены способа осуществлять над ними контроль версий. То есть вы не можете управлять изменениями, возвращаться к предыдущей версии (без восстановления резервной копии всей базы) и отслеживать изменения между версиями. Итак, храните исходные тексты ваших объектов в файлах со сценариями.

[В начало]

Сценарии должны быть раздельными

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

[В начало]

Не используйте Unicode

Сохраняйте каждый файл со сценарием в кодировке ANSI. Не все системы контроля версий могут использовать Unicode (текущая версия VSS не может), и хотя эта кодировка является параметром по умолчанию в мастере создания сценариев Enterprise Manager, ее не следует использовать, если вы не хотите потерять совместимость с большинством средств для работы с текстовыми файлами. Например, вы можете поместить файл в Unicode-кодировке в VSS, но он обрабатывается как бинарный файл, поскольку VSS не распознает кодировку Unicode. А это означает, что вы не сможете отслеживать изменения между версиями таких файлов, что является серьезным ограничением.

[В начало]

Используйте метки для обозначения версий

Большинство систем контроля версий обладают возможностью, которая поз­воляет помечать версию вашего программного кода так, что вы можете впо­следствии, благодаря этому, иметь ссылку на версию как на связанную группу файлов. Используйте эту возможность для пометки версии программного обеспечения или приложения. Впоследствии это избавит вас от лишних хлопот. Очевидно, что разные части кода меняются с разной частотой. Номера их внутренних версий будут отличаться. Тем не менее, если вы присвоите метку, обозначающую общую версию, всем файлам, входящим в текущий релиз программного продукта, вы сможете получить и скомпилировать этот релиз, как только возникнет необходимость, не нуждаясь в ручной синхронизации разных номеров внутренних версий файлов.

[В начало]

Используйте ключевые слова

Общая возможность систем контроля версий - средство, позволяющее вносить в исходные тексты специальные ключевые слова, которые могут послужить расширенной информацией при регистрации изменений в файлах. В VSS эта возможность известна как ключевые слова, которые позволяют записывать такую полезную информацию, как: имя разработчика, внесшего последние изменения в файл; дату и время последнего изменения; номер внутренней версии файла и много других полезных вещей в сами файлы с исходными текстами.

Ключевые слова VSS заключены между двумя символами $. Например, для записи имени автора данного исходного файла в этот файл используется ключевое слово $Author $. При регистрации изменений ключевое слово $Author $ будет заменено именем пользователя VSS, который последним внес изменения в файл.

Как правило, вы вставляете эти ключевые слова в комментарии, что не затрагивает ваш код. Хорошее место для размещения этих комментариев - заголовок вашего файла со сценарием. Ниже приведен пример часто используемого мной блока комментария на Transact‑SQL.

Листинг 4.1. Пример блока комментариев

Object: sp_usage Description: Provides usage information for stored procedures and descriptions of other types of objects Usage: sp_usage @objectname='ObjectName', @desc='Description of object' [, @parameters='param1,param2...'] [, @example='Example of usage'] [, @workfile='File name of script'] [, @author='Object author'] [, @email='Author email'] [, @version='Version number or info'] [, @revision='Revision number or info'] [, @datecreated='Date created'] [, @datelastchanged='Date last changed'] Returns: (None) $Workfile: sp_usage.sql $ $Author: Khen$. Email: khen@khen.com $Revision: 7 $ Example: sp_usage @objectname='sp_who', @desc='Returns a list of currently running jobs', @parameters=[@loginname] Created: 1992-04-03. $Modtime: 4/07/00 8:38p $. */

Обратите внимание, что VSS вставил текст в каждую метку ключевого слова. В случае $Workfile $ VSS вставил sp_usage.sql. В случае $Author $ было вставлено khen.

ВНИМАНИЕ

Ключевые слова VSS чувствительны к регистру. Если вы используете VSS и решили вставлять ключевые слова в ваши исходные файлы на Transact-SQL, убедитесь, что вы их вводите в требуемом регистре. Если вы использовали ключевые слова и заметили, что некоторые из них не были коррект­но восприняты VSS, проверьте регистр.

Параметр использования ключевых слов VSS включается с помощью программы VSS Administrator для каждого типа файлов по его расширению. Чтобы включить использование для отдельного типа файлов, перейдите на вкладку General в диалоге ToolsOptions программы VSS Administrator. В окне ввода Expand keywords in files of type введите маску файлов, в которых будут использоваться ключевые слова (например, *.SQL). В табл. 4.1 приведен список ключевых слов VSS и их значения.

Таблица 4.1. Ключевые слова VSS их значение

Ключевые слова

Значения, подставляемые VSS

$Author: $

Имя пользователя, который последним изменил файл

$Modtime: $

Дата и время последнего изменения

$Revision: $

Номер внутренней версии VSS

$Workfile: $

Имя файла

$Archive: $

Имя архива VSS

$Date: $

Дата и время последней регистрации изменений

$Header: $

Комбинация меток $Logfile: $, $Revision: $, $Date: $ и $Author: $

$History: $

История файла в формате VSS

$JustDate: $

Дата последней регистрации изменений

$Log: $

История файла в формате RCS

$Logfile: $

Дубликат метки $Archive: $

$NoKeywords: $

Выключить использование ключевых слов

[В начало]

Не используйте шифрование

При распространении своих приложений на основе SQL Server пользователям и дру­гим третьим сторонам вы, возможно, можете поддаться искушению зашифровать программный код ваших хранимых процедур, функций и других подобных объектов, предполагая, что это защитит ваш код от любопытных глаз, а также от несанкционированного изменения вашего кода.

Хочу вас предостеречь: пока вы не имеете дело с хищением конфиденциальной или частной информации, я не советую вам шифровать объекты. Исходя из моего опыта, шифрование объектов SQL Server обычно приносит больше проблем, нежели пользы. У шифрования исходных текстов объектов SQL Server существует целый ряд отрицательных сторон. Обсудим некоторые из них.

Первое: невозможно создать сценарий шифрованных объектов даже с помощью Enterprise Manager. То есть, если вы однажды зашифровали процедуру или функцию, вы не сможете получить ее исходный текст из SQL Server. Хорошо известные, но недокументированные методы дешифрации зашифрованных объектов, которые существовали в ранних версиях SQL Server, больше не работают, а другие методы, которые могут быть использованы, - не поддерживаются Microsoft. Ко всему прочему, если вы попытаетесь создать сценарий зашифрованного объекта с помощью Enterprise Manager, используя настройки по умолчанию, ваш сценарий будет содержать для каждого объекта вместо CREATE команду DROP. Все, что вы увидите в действительности, - "полезный" комментарий, информирующий вас о том, что невозможно создать сценарий зашифрованного объекта (притом, что в действительности создается сценарий, уничтожающий объект). Если вы запустите этот сценарий, ваш объект будет потерян. Он не будет создан, а будет удален.

Второе: зашифрованные объекты не могут быть опубликованы как часть репликации SQL Server. При использовании механизма репликации для синхронизации нескольких серверов у ваших клиентов они окажутся в сложном положении, если ваш код будет зашифрован.

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

В листинге 4.2 показана хранимая процедура, которую вы можете использовать для отображения информации о версии объектов вашего SQL Server. В ней в основном производится поиск в таблице syscomments ключевых слов VSS и генерируется отчет по объектам, содержащим эти ключевые слова. Запуск этой процедуры может дать вам общее представление о данных версии для всего кода Transact-SQL в вашей базе данных.

Листинг 4.2. Процедура для вывода информации о версии VSS хранимых процедур

USE master GO IF OBJECT_ID('dbo.sp_GGShowVersion') IS NOT NULL DROP PROC dbo.sp_GGShowVersion GO CREATE PROC dbo.sp_GGShowVersion @Mask varchar(30)='%', @ObjType varchar(2)='%' /* GGVersion: 2.0.1 Object: sp_GGShowVersion Description: Shows version, revision and other info for procedures, views, triggers, and functions Usage: sp_GGShowVersion @Mask, @ObjType -- @Mask is an object name mask (supports wildcards) indicating which objects to list @ObjType is an object type mask (supports wildcards) indicating which object types to list Supported object types include: P Procedures V Views TR Triggers FN Functions Returns: (none)

Листинг 4.2 (продолжение)

$Workfile: sp_ggshowversion.SQL $ $Author: Khen $. Email: khen@khen.com $Revision: 1 $ Example: sp_GGShowVersion Created: 2000-04-03. $Modtime: 4/29/00 2:49p $. */ AS DECLARE @GGVersion varchar(30), @Revision varchar(30), @author varchar(30), @Date varchar(30), @Modtime varchar(30) SELECT @GGVersion='GGVersion: ',@Revision='$'+'Revision: ',@Date='$'+'Date: ', @Modtime='$'+'Modtime: ',@Author='$'+'Author: ' SELECT DISTINCT Object=SUBSTRING(o.name,1,30), Type=CASE o.Type WHEN 'P' THEN 'Procedure' WHEN 'V' THEN 'View' WHEN 'TR' THEN 'Trigger' WHEN 'FN' THEN 'Function' ELSE o.Type END, Version=CASE WHEN CHARINDEX(@GGVersion,c.text)<>0 THEN SUBSTRING(LTRIM(SUBSTRING(c.text,CHARINDEX(@GGVersion,c.text)+LEN(@GGVersio n),10)),1,ISNULL(NULLIF(CHARINDEX(CHAR(13),LTRIM(SUBSTRING(c.text,CHARINDEX (@GGVersion,c.text)+LEN(@GGVersion),10)))-1,-1),1)) ELSE NULL END, Revision=CONVERT(int, CASE WHEN CHARINDEX(@Revision,c.text)<>0 THEN SUBSTRING(LTRIM(SUBSTRING(c.text,CHARINDEX(@Revision,c.text)+LEN(@Revision) ,10)) ,1,ISNULL(NULLIF(CHARINDEX(' ',LTRIM(SUBSTRING(c.text,CHARINDEX(@Revision,c.text)+LEN(@Revision),10)))- 1,-1),1)) ELSE '0' END), Created=o.crdate, Owner=SUBSTRING(USER_NAME(uid),1,10), 'Last Modified By'= SUBSTRING(LTRIM(SUBSTRING(c.text,CHARINDEX(@Author,c.text)+LEN(@Author),10) ),1,ISNULL(NULLIF(CHARINDEX(' $',LTRIM(SUBSTRING(c.text,CHARINDEX(@Author,c.text)+LEN(@Author),10)))-1,- 1),1)), 'Last Checked In'=CASE WHEN CHARINDEX(@Date,c.text)<>0 THEN SUBSTRING(LTRIM(SUBSTRING(c.text,CHARINDEX(@Date,c.text)+LEN(@Date),15)),1, ISNULL(NULLIF(CHARINDEX(' $',LTRIM(SUBSTRING(c.text,CHARINDEX(@Date,c.text)+LEN(@Date),20)))-1,- 1),1)) ELSE NULL END, 'Last Modified'=SUBSTRING(LTRIM(SUBSTRING(c.text,CHARINDEX(@Modtime,c.text)+LEN(@ Modtime),20)),1,ISNULL(NULLIF(CHARINDEX(' $',LTRIM(SUBSTRING(c.text,CHARINDEX(@Modtime,c.text)+LEN(@Modtime),20)))- 1,-1),1)) FROM dbo.syscomments c RIGHT OUTER JOIN dbo.sysobjects o ON c.id=o.id WHERE o.name LIKE @Mask AND (o.type LIKE @ObjType AND o.TYPE in ('P','V','FN','TR')) AND (c.text LIKE '%'+@Revision+'%' OR c.text IS NULL) AND (c.colid=(SELECT MIN(c1.colid) FROM syscomments c1 WHERE c1.id=c.id) OR c.text IS NULL) ORDER BY Object GO GRANT ALL ON dbo.sp_GGShowversion TO public GO EXEC dbo.sp_GGShowVersion

(Результаты сокращены)

Object Type Version Revision Created ------------------------ --------- -------- -------- --------------------- sp_created Procedure NULL 2 2000-04-08 00:19:51.680 sp_GGShowVersion Procedure 2.0.1 1 2000-04-29 15:30:56.197 sp_hexstring Procedure NULL 1 2000-04-08 15:12:21.610 sp_object_script_commentsProcedure NULL 1 2000-04-29 12:59:08.250 sp_usage Procedure NULL 6 2000-04-07 20:37:54.930

Эта процедура предоставляет информацию о ключевых словах VSS, которые я использую чаще всего, но может быть легко модифицирована для поиска информации о любом ключевом слове. Обратите внимание на пользовательскую метку GGVersion. Вы можете использовать эту метку для связи исходного текста на Trans­act‑SQL с версией вашего приложения. Для форматирования GGVersion я использовал традиционное представление поля VERSIONINFO (информация о продукте в Windows), которое состоит из четырех частей - четвертая часть берется из значения метки VSS $Revision $.

[В начало]

Контроль версий из Query Analyzer

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

Как я уже упоминал, я использую VSS, поэтому нижеописанные шаги показывают, как использовать утилиту командной строки VSS SS.EXE из Query Analyzer. Это не значит, что вы не можете из Query Analyzer использовать другую систему контроля версий. Напротив, поскольку большинство систем контроля версий работают почти одинаково, шаги, необходимые для доступа к утилитам командной строки, схожи, независимо от используемого инструментария.

Для добавления внешних средств к меню Tools Query Analyzer в главном меню выберите Tools4Customize и затем в окне Customize выберите вкладку Tools. В элементе ввода Menu contents в центре страницы перечислены инструменты, установленные в настоящее время. Для добавления нового элемента сделайте двойной щелчок на пустой строке списка. Таблица 4.2 показывает элементы в моем списке, связанные с использованием VSS.

Таблица 4.2. Элементы меню, связанные с использованием VSS

Название

Команда

Аргументы

Начальный директорий

Set Project Path

ss.exe

cp $/ggspxml/ch04/code

 

Set Working folder

ss.exe

workfold $(FileDir)

 

Add Current File

ss.exe

add $(FilePath)

$(FileDir)

Check Out Current File

ss.exe

checkout $(FileName) $(FileExt) -C-

$(FileDir)

Check In Current File

ss.exe

checkin $(FileName) $(FileExt)

$(FileDir)

Undo Check Out of Current File

ss.exe

undocheckout $(FileName) $(FileExt)

$(FileDir)

Diff Current File

Diff.bat

$(FileName)$(FileExt)

$(FileDir)

После настройки Query Analyzer вам необходимо убедиться в следующем. Во-первых, проверьте, что пункты Set Project Path и Set Working Folder используют ­настройки вашей папки проекта и рабочей папки соответственно. Значения, перечис­ленные в табл. 4.2, отображают мои настройки на текущий момент. Во-вторых, имейте в виду, что большинство команд VSS при вызове предлагают ввести комментарий. Я блокировал ввод комментария для команды Check Out Current File, оставив эту возможность для других. Добавьте -C- к любой команде, для которой вы хотите заблокировать приглашение к вводу комментария. В-третьих, установите переменную окружения SSDIR, указывающую на папку, содержащую файл SRCSAFE.INI, если она отличается от пути поиска VSS, заданного по умолчанию.

Обратите внимание на командный файл DIFF.BAT, который используется для проверки файла на различия версий. DIFF.BAT содержит всего две строчки:

ss diff %1 pause

Первая строка отображает различия между локальной версией данного файла и версией, хранящейся в базе данных VSS. Команда pause позволяет увидеть различия до возврата в Query Analyzer. Мы вызываем DIFF.BAT вместо того, чтобы непосредственно вызвать ss diff, поскольку мы хотим увидеть результаты работы команды до возврата в среду Query Analyzer.

[В начало]

Специальные лексемы

Как вы видели, Query Analyzer поддерживает несколько специальных маркеров (обозначаемых символом $), которые вы можете использовать для передачи информации времени исполнения внешним программам. Для получения списка до­ступных лексем щелкните на кнопке со стрелкой справа от элементов Arguments и Initial directory. В табл. 4.3 перечислены используемые мной лек­семы.

Таблица 4.3. Лексемы времени исполнения Query Analyzer

Лексема

Значение

$(FilePath)

Полный путь к текущему файлу

$(FileName)

Имя текущего файла (без расширения)

$(FileExt)

Расширение (включая точку) текущего файла

$(FileDir)

Путь к текущему файлу (без имени файла и расширения)

ВНИМАНИЕ

Возможно, вы заметили, что Query Analyzer при редактировании добавляет звездочку к заголовку окна текущего файла. Поскольку Query Analyzer получает имя файла из заголовка окна, к значениям лексем $(FileExt) и $(FilePath), передаваемым во внешние программы, ошибочно добавляется звездочка. Таким образом, если вы изменили файл, во внешние программы будет передано неверное значение. Чтобы обойти это препятствие, просто сохраните файл, прежде чем вызвать команду. Так или иначе, вы должны убедиться, что система имеет дело с последней версией файла.

На компакт-диске, прилагаемом к этой книге, вы можете найти файл с расширением REG, содержащий элементы реестра, необходимые для добавления этих лексем к вашей установке Query Analyzer. Для добавления настроек, приведенных в табл. 4.3 к вашей установке Query Analyzer, запустите этот .REG-файл.

[В начало]

Автоматизация создания сценариев при помощи контроля версий

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

В VSS этот API в действительности представляет собой COM-интерфейс, доступ к которому можно получить из любой среды разработки, поддерживающей автоматизацию (например, Visual Basic или Delphi). Используя интерфейс автоматизации VSS, вы можете делать, по существу, все то же самое, что и Проводник VSS, поскольку он сам использует тот же интерфейс. Посредством довольно простого программного кода вы можете программно оперировать версиями проекта VSS, помечая файлы и регистрируя изменения, извлекая определенные версии проекта и т. д.

[В начало]

GGSQLBuilder

Примером того, насколько это просто и вместе с тем эффективно, является утилита, написанная на Delphi, которая ищет в проекте VSS сценарии SQL и извлекает их в два файла со сценариями T‑SQL, которые затем можно запустить на выполнение. GGSQLBuilder находит в проекте каждый файл со сценарием SQL, затем просматривает все версии этого файла и находит последний, помеченный меткой (это предполагает, что перед выпуском вы помечаете версию - обычная практика), или первую версию файла, если не найдено ни одной метки. Как только найдена требуемая версия каждого файла, он добавляется в общий сценарий для построения всей базы данных.

GGSQLBuilder может быть использован в интерактивном режиме, а также вы­зван из командной строки. При интерактивном использовании он функционирует как мастер: он предлагает ввести вам данные, необходимые для нахождения файлов со сценариями создания объектов, и выбрать имя для выходных файлов. В результате он находит и извлекает ваши сценарии. Используя интерфейс командной строки GGSQLBuilder, можно полностью автоматизировать регулярную сборку общего сценария.

[В начало]

Принцип работы GGSQLBuilder

Я уже упоминал, что GGSQLBuilder извлекает ваши сценарии в два файла сценариев T‑SQL. Почему в два? Дело в том, что GGSQLBuilder разработан для формирования сценариев клиентских приложений, которые построены на основе SQL Server. Он специально разработан для помощи в создании сценариев для установки и обновления таких приложений.

Обычно клиентские приложения на основе SQL Server вынуждены использовать две базы данных: одна или несколько пользовательских баз данных и база данных master. Как вы можете предположить, пользовательская база данных обычно хранит данные конечного пользователя и T‑SQL-код объектов, специфичных для данного приложения, таких как хранимые процедуры и представления. С другой стороны, в базе данных master обычно располагаются хранимые процедуры и функции либо системного назначения, либо использующиеся в нескольких базах данных. Как правило, в базе данных master не должно храниться ничего, чтобы не удовлетворяло этому критерию. GGSQLBuilder задуман таким образом, чтобы сделать извлечение сценариев этих двух видов безболезненным. Как только эти два файла сформированы, вы можете запустить на исполнение получившиеся сценарии на всех необходимых пользовательских базах данных. Например, если вы намерены использовать итоговый сценарий как часть обновления программного обеспечения, ваш пакет обновления может вызвать утилиту OSQL, используя флаг ‑d для определения базы данных, в которой должен быть исполнен сценарий. Вы легко можете автоматизировать распространение сценария на несколько баз данных конечных пользователей, последовательно вызывая OSQL из командной строки.

Что касается сценария для базы данных master, в процессе обновления вашего программного обеспечения вы, как правило, должны запустить его однократно. Он установит или обновит системные объекты в базе данных master, которые могут быть использованы в системе повсюду, в любой базе данных.

[В начало]

Преимущества средств формирования сценариев

Чем, в первую очередь, вас могло бы привлечь средство GGSQLBuilder и подобные ему? Почему бы просто не выгрузить отдельный сценарий для каждого объекта или не использовать Enterprise Manager или что‑либо подобное для формирования единого файла сценария? Первое: развертывание сотен или даже тысяч отдельных сценариев у конечных пользователей может оказаться проблематичным. Каждый дополнительно распространяемый файл увеличивает вероятность, что установка или обновление закончатся неудачно. Второе: если при каждом обновлении программного обеспечения вы не перестраиваете данные пользователей, сценарий, формируемый Enterprise Manager, не подходит для обновлений. Вы, вероятно, не захотели бы включать команды DROP/CREATE TABLE в ваш сценарий для обновления существующей базы данных.

[В начало]

Как GGSQLBuilder находит и упорядочивает сценарии

Как GGSQLBuilder узнает, что считать сценарием SQL и в какой файл необходимо его извлечь? Он работает исходя из предположений, что ваш проект VSS организован таким образом, что:

  1. сценарии проекта располагаются в папках подчиненных проектов, имена которых перечислены в табл. 4.4;

  2. все сценарии, которые должны быть выполнены в базе данных master, расположены в подчиненном проекте с именем MasterDB;

  3. он находит в вашем дереве проектов VSS сценарии SQL по расширению файлов. По умолчанию файлы с расширениями, перечисленными в табл. 4.5, считаются сценариями T‑SQL.

Таблица 4.4. Папки VSS, распознаваемые GGSQLBuilder

Имя папки

Тип

MasterDB

Сценарии для выполнения в базе данных master

Defaults

Объекты умолчаний (например, CREATE DEFAULT)

Rules

Объекты правил (например, CREATE RULE)

Tables

Объекты таблиц (например, CREATE TABLE)

TableAlters

Модификация таблиц (например, ALTER TABLE)

Triggers

Объекты триггеров (например, CREATE TRIGGER)

UDFs

Объекты пользовательских функций (например, CREATE FUNCTION)

Views

Объекты представлений (например, CREATE VIEW)

StoredProcs

Объекты хранимых процедур (например, CREATE PROC или ALTER PROC)

Обратите внимание, что папки в табл. 4.4 перечислены в порядке зависимостей объектов. Вероятно, что существование объектов в базе данных masters будет необходимо до создания пользовательских объектов, объекты значений по умолчанию должны быть созданы прежде таблиц, которые их используют, таблицы - прежде выполнения сценариев, которые их изменяют и т. д. Пользуясь приведенным в табл. 4.4 порядком папок, GGSQLBuilder запишет найденные в вашей базе данных VSS сценарии в итоговые сценарии. В табл. 4.5 перечислены расширения файлов, распознаваемые GGSQLBuilder.

Таблица 4.5. Расширения файлов, распознаваемые GGSQLBuilder по умолчанию

Расширение

Тип файла

SQL

Сценарий SQL общего назначения

PRC

Хранимые процедуры

TRG

Триггеры

UDF

Пользовательские функции

TAB

Таблицы

VIW

Представления

DEF

Умолчания

RUL

Правила

UDT

Пользовательские типы данных

FTX

Полнотекстовые индексы

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

Лучший путь изучения GGSQLBuilder - запустить его в интерактивном режиме. Если у вас есть база данных VSS, содержащая некоторое количество включенных в нее сценариев SQL, не задумываясь, запускайте GGSQLBuilder. Пусть он попробует найти эти сценарии. Если иерархия проекта велика, вы заметите некоторую задержку: GGSQLBuilder будет исследовать каждую версию каждого файла в дереве проекта. Если вы сгруппировали ваши проекты со сценариями вместе (согласно табл. 4.4) в единый родительский проект, вы можете настроить GGSQLBuilder на поиск, начиная с этого проекта. Как только GGSQLBuilder найдет ваши сценарии, позвольте ему продемонстрировать свою работу и построить два итоговых файла со сценариями.

ВНИМАНИЕ

Поскольку GGSQLBuilder распознает сценарии SQL, основываясь только лишь на расширениях файлов, возможно, что созданные им итоговые сценарии будут содержать нежелательные команды создания или уничтожения объектов. Иными словами, если вы зарегистрировали в VSS сценарий по созданию таблицы, вы, в конце концов, можете получить сценарий, содержащий не только команду CREATE TABLE, но также и команду DROP TABLE, если она содержалась в исходном сценарии. Мораль заключается в следующем: используйте дерево проектов GGSQLBuilder для тщательного иссле­дования содержащихся в нем сценариев SQL и снимите пометку с тех, которые не должны появиться в итоговом сценарии.

Поэкспериментируйте с GGSQLBuilder и посмотрите, насколько он мог бы быть полезен в разработке обновлений для приложений, основанных на использовании SQL Server, автоматизации сборок сценариев и тестирования. Однако имейте в виду одну вещь: средства подобные GGSQLBuilder будут бесполезны для вас, пока ваш T‑SQL-код не будет храниться в системах контроля версий.

[В начало]

Итоги

В этой главе вы узнали:

  • о системах контроля версий и преимуществах их использования для управления кодом T‑SQL;

  • о T‑SQL как о настоящем коде; о коде, нуждающемся в управлении (как и любой тип программного кода);

  • о некоторых приемах, которые делают использование систем контроля версий для Transact‑SQL максимально полезным;

  • об использовании двух новых программ, которые работают совместно с VSS;

  • о необходимости управлять своим программным кодом и использовать системы контроля версий независимо от исходного инструментария и языка программирования.

[В начало]

Перевод: Издательского дома ПИТЕР  2005г.

Rambler's Top100 Рейтинг@Mail.ru  Administrator: Обратная связь 
Copyright: SQL.Ru 2000-2013