Здравствуйте, VladD2, Вы писали:
VD>Повторять 25 раз, что для этого в грамотном решении используют шаблону я уже устал. VD>Делай как хочешь. Тебе указали на ошибки. Тебе решать проигнорировать замечания или принять к сведению.
Для внесения таких зависисмостей в проект мне требуются более понятные аргументы, чем "тебе 25 раз сказали, что надо использовать".
Z>>Продолжаю не понимать смысла притягивания в проект StringTemplate. Все что ты продемонстрировал делается с помощью $"" точно так же.
VD>$-строки: VD>1. Не позволяют изменять реализацию наследованием.
$(base.DropColumn(table, column)) нельзя написать?
VD>2. Менее эффективны (не рассчитаны на потоковый вывод).
Формируется команда и отдается серверу на исполнение. Зачем здесь применять потоковый вывод
VD>3. Не поддерживают того самого наследования.
Понял не больше чем первый пункт.
VD>4. Не обеспечивают отслеживание отступов. Посмотри на вывод тестов. Там любая вложенная конструкция качественно "отбита" в соответствии со своим уровнем вложенности.
Сервер переживет код без отступов.
VD>В общем, если ты будешь пытаться реализовать тоже самое на $-строках, то будешь изобретать свой велосипед.
Что реализовать-то? Объясни нормально.
VD>В рельсах мне не приходится писать на конкретных диалектах SQL. Если у тебя это потребуется, то это уже явный недостаток.
VD>Вообще глупо брать библиотеку вроде рельсов и начинать писать свои хранимки, триггеры и т.п. Более умно было реализовать всю нужную инфраструктуру на основе сервера приложений.
Глупо брать библиотеку не убедившись в том, что эти хранимки не станут проблемой при оптимизации.
VD>Но если даже нужно дать возможность писать код на диалекте SQL, то опять же нужно предоставить прикладным программистам возможность абстрагироваться от конкретных СУБД. Опять же идея сменных шаблонов тут будет рулить.
Идею ты так и не озвучил нормально. Давай для тупых, расскажи как ты это видишь.
Z>>Это все есть.
VD>Где можно посмотреть?
на гуглкоде. В проекте NRails.Demo есть файлик migrate.cmd, правда он еще не умеет компилить миграции, NRails.Demo.Migrations надо сбилдить руками.
Здравствуйте, Ziaw, Вы писали:
Z>Для внесения таких зависисмостей в проект мне требуются более понятные аргументы, чем "тебе 25 раз сказали, что надо использовать".
То что ты аргументы игнорируешь не значит, что их не было.
Z>>>Продолжаю не понимать смысла притягивания в проект StringTemplate. Все что ты продемонстрировал делается с помощью $"" точно так же.
VD>>$-строки: VD>>1. Не позволяют изменять реализацию наследованием.
Z>$(base.DropColumn(table, column)) нельзя написать?
Написать то конечно можно, только это будет не тоже самое, что подмена реализации шаблона.
VD>>2. Менее эффективны (не рассчитаны на потоковый вывод).
Z>Формируется команда и отдается серверу на исполнение. Зачем здесь применять потоковый вывод
Не потоковый вывод, а потоковую модель формирования конечных строк. StringTemplate создан на одной базе с $-строками. Разница только в том, что он работает значительно быстрее (на больших строках) и гибче.
Грубо говоря весь StringTemplateGrup фомрирует строку в едином StringBuilder в то время как $-строки используют конкатенацию строк. В общем, StringTemplate рассчитан на большие динамические строки, а $-строка на относительно маленькие и формируемые из относительно небольшого числа элементов.
VD>>4. Не обеспечивают отслеживание отступов. Посмотри на вывод тестов. Там любая вложенная конструкция качественно "отбита" в соответствии со своим уровнем вложенности.
Z>Сервер переживет код без отступов.
Сервер то без сомнений переживет. Люди не переживут! Это ведь не просто SQL-скрипт. Это код динамически формируемый по шаблонам. Его ведь еще отлаживать надо. Иногда придется тем же SqlProfiler воспользоваться или просто в логи заглянуть. А там будет ужасно сваленный в кучу текст, вместо хорошо отформатированного SQL-кода.
Ну, да похоже это для тебя тоже не аргумент.
VD>>В общем, если ты будешь пытаться реализовать тоже самое на $-строках, то будешь изобретать свой велосипед.
Z>Что реализовать-то? Объясни нормально.
Да все что перечислено. В прочем это все для тебя не аргументы.
Есть две категории людей. Первая учится на своих и чужих ошибках. Вторая только на чужих. Вот ты похоже из второй категории. Переубедить тебя видимо не получится. Так что набивай свои шишки.
VD>>Вообще глупо брать библиотеку вроде рельсов и начинать писать свои хранимки, триггеры и т.п. Более умно было реализовать всю нужную инфраструктуру на основе сервера приложений.
Z>Глупо брать библиотеку не убедившись в том, что эти хранимки не станут проблемой при оптимизации.
Если эти хранимки придется писать только для оптимизации, то это куда не шло. Оптимизация нужна 2-3 раза на проект. А вот если это будет штатным трахом, то я бы такую библиотеку не стал испльзовать.
Z>Идею ты так и не озвучил нормально. Давай для тупых, расскажи как ты это видишь.
Вообще-то я уже рассказывал...
Идея очень простая. Ты создаешь некий абстрактный DDL описывающий трансформации сущностей СУБД. Далее ты создаешь базовую группу шаблонов (аналогично классу) где для каждого элемента твоего абстрактного DDL-я имеется шаблон генерирующий текст (прикладной SQL). Этот базовый шаблон генерирует код на некотором диалекте SQL, напирмер, на TSQL. Далее ты (или кто-то другой) создаешь наследников этой группы шаблонов для каждой поддерживаемой СУБД и переопределяешь в нем реализацию тех элементов которые отличаются.
В таких шаблонах можно будет использовать конкретный синтаксис конкретной СУБД. В том числе можно будет делать проверки наличия констрэйнов и удалять их если нужно (что актуально для MS SQL).
Далее в реальных проектах используем не прямой вызов группы шаблонов, а динамическую его загрузку (например, на базе фабрики классов). В реальном проекте прописываем имя (в виде атрибута, например) и загружаем указанную группу. Это позволяет пользователю подсунуть свою группу унаследованную от базовой (или одного из его потомков) и переопределяющий те или иные шаблоны, что позволяет адаптировать генерируемый миграциями код под собственные нужды, но при этом не создавать решение для одной СУБД просто "потому что это проще".
Z> на гуглкоде. В проекте NRails.Demo есть файлик migrate.cmd, правда он еще не умеет компилить миграции, NRails.Demo.Migrations надо сбилдить руками.
Проще было дать ссылку на файл.
Я что-то там посмотрел, но вместо красивого ДСЛ-я увидил какую-то кучу вложенных лямбд. Это оно?
Если — да, то что с ДСЛ-ем?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>То что ты аргументы игнорируешь не значит, что их не было.
Я по каждому коментарий написал.
Z>>>>Продолжаю не понимать смысла притягивания в проект StringTemplate. Все что ты продемонстрировал делается с помощью $"" точно так же.
VD>>>$-строки: VD>>>1. Не позволяют изменять реализацию наследованием.
Z>>$(base.DropColumn(table, column)) нельзя написать?
VD>Написать то конечно можно, только это будет не тоже самое, что подмена реализации шаблона.
Тогда объясни как выглядит подмена реализации шаблона, если это не наследование
VD>>>2. Менее эффективны (не рассчитаны на потоковый вывод).
Z>>Формируется команда и отдается серверу на исполнение. Зачем здесь применять потоковый вывод
VD>Не потоковый вывод, а потоковую модель формирования конечных строк. StringTemplate создан на одной базе с $-строками. Разница только в том, что он работает значительно быстрее (на больших строках) и гибче. VD>Грубо говоря весь StringTemplateGrup фомрирует строку в едином StringBuilder в то время как $-строки используют конкатенацию строк. В общем, StringTemplate рассчитан на большие динамические строки, а $-строка на относительно маленькие и формируемые из относительно небольшого числа элементов.
Даже если я буду посимвольно складывать этот шаблон, это будет незаметно на фоне выполнения этого запроса. Там на порядки разные сложности. Хреновый аргумент.
VD>>>4. Не обеспечивают отслеживание отступов. Посмотри на вывод тестов. Там любая вложенная конструкция качественно "отбита" в соответствии со своим уровнем вложенности.
Z>>Сервер переживет код без отступов.
VD>Сервер то без сомнений переживет. Люди не переживут! Это ведь не просто SQL-скрипт. Это код динамически формируемый по шаблонам. Его ведь еще отлаживать надо. Иногда придется тем же SqlProfiler воспользоваться или просто в логи заглянуть. А там будет ужасно сваленный в кучу текст, вместо хорошо отформатированного SQL-кода.
VD>Ну, да похоже это для тебя тоже не аргумент.
У меня вполне читаемый sql получается. Конечно не идеально отформатированный, но для чтения человеком вполне достаточно.
VD>Да все что перечислено. В прочем это все для тебя не аргументы. VD>Есть две категории людей. Первая учится на своих и чужих ошибках. Вторая только на чужих. Вот ты похоже из второй категории. Переубедить тебя видимо не получится. Так что набивай свои шишки.
Да нет, аргументы подкачали. По крайней мере те, которые я смог понять. Кидаться переписывать драйвер БД изза них я не буду. У текущего драйвера есть большой плюс, он дернут из януса и оттуда же можно дернуть для других БД. Написать с нуля и протестить темплейты для всех БД я один не в состоянии.
Z>>Идею ты так и не озвучил нормально. Давай для тупых, расскажи как ты это видишь.
VD>Вообще-то я уже рассказывал... VD>Идея очень простая. Ты создаешь некий абстрактный DDL описывающий трансформации сущностей СУБД. Далее ты создаешь базовую группу шаблонов (аналогично классу) где для каждого элемента твоего абстрактного DDL-я имеется шаблон генерирующий текст (прикладной SQL). Этот базовый шаблон генерирует код на некотором диалекте SQL, напирмер, на TSQL. Далее ты (или кто-то другой) создаешь наследников этой группы шаблонов для каждой поддерживаемой СУБД и переопределяешь в нем реализацию тех элементов которые отличаются.
Наконец что-то более менее понятное. Где доки по всему этому?
VD>В таких шаблонах можно будет использовать конкретный синтаксис конкретной СУБД. В том числе можно будет делать проверки наличия констрэйнов и удалять их если нужно (что актуально для MS SQL).
Пока не очень акутально. Констрейнты тоже входят в модель схемы, проверки лучше делать в ней.
VD>Проще было дать ссылку на файл.
[StringTemplateGroup]
class BaseTamplate
{
...
public virtual DropColumn(table : Table, column : Column) {<#
$"ALTER TABLE $(table.Name) DROP COLUMN $(column.Name)"
#>}
...
}
А, скажем в шаблоне для MS SQL 2008:
[StringTemplateGroup]
class MsSql2008 : BaseTamplate
{
...
publicoverride DropColumn(table : Table, column : Column) {<#
if exists (select 1 from syscolumns where id = object_id("$(table.Name)") and name = "$(column.Name)")
begin
$(base.DropColumn(table, column))
end
#>}
...
}
или еще что-то.
главное здесь не вызов "base.DropColumn(table, column)" (без него можно обойтись).
Главное здесь, то что шаблон (то что выглядит как функция) переопределяет (override, выделено жирным) шаблон объявленный в базовой группе шаблонов.
Пользователь может заменить этот шаблон, но не может налепить черти чего.
Z>Даже если я буду посимвольно складывать этот шаблон, это будет незаметно на фоне выполнения этого запроса. Там на порядки разные сложности. Хреновый аргумент.
Глупость не говори. Попробуй на досуге посимвольно конкатенировать строки. Увидишь, что даже на небольших строках начнутся тормоза, так как это экспонента.
С применением $-строк конечно такого не произойдет (точнее получить экспоненту будет сложно, но можно), но зачем же намеренно выбирать худший путь?
Z>У меня вполне читаемый sql получается. Конечно не идеально отформатированный, но для чтения человеком вполне достаточно.
Читаемый без отступов? У нас видимо диаметрально противоположенные понятия о читаемости.
А зачем не идеальный, когда можно получить идеально отформатированный код?
В общем, "упорству храбрых поем мы песню...". Через зад но по-своему.
Z>Да нет, аргументы подкачали.
На мой взгляд, тех что есть выше крыши. У меня нет задачи убедить тебя во что-бы то ни стало.
Z>По крайней мере те, которые я смог понять.
Если ты не понимаешь сказанного, то хорошо бы задуматься над тем почему это происходит. Возможно тебе плохо объясняют. Тогда стоит уточнить детали. А возможно дело в тебе. Если стараться не понять, то точно не поймешь.
Z>Кидаться переписывать драйвер БД изза них я не буду.
У... В нашем деле — это никудышная позиция. Я порой переписываю код по 5 раз только для того чтобы удовлетворить свое чувство прекрасного. Ты делаешь то, что до тебя никто не делал, так что эксперименты — это главный способ выбора лучших решений.
Ведь у тебя еще не готовы драйверы для всех поддерживаемых БЛТулкитом СУБД?
Найти в коде проекта код связанный с драйверами было очень не просто.
Ты конечно снова можешь не слушать моих советов, но я бы посоветовал не сваливать в один файл кучу классов, даже если каждый из них очень маленький. Ни компилятор, ни IDE не напряжет если ты разложишь типы отдельные файлы. А вот люди будут ориентироваться в коде намного проще.
Для драйверов нужно создать отдельный каталог, который так и назвать.
Кстати, зачем было выбирать Меркури в качестве сорс-контрола? У меня на машине даже нечем скачать код.
Пришлось тратить время на поиск и установку клиента.
SVN вроде бы вполне приемлем для открытых проектов и его криент есть почти у всех. Тем самым ты сужаешь аудиторию.
Z>У текущего драйвера есть большой плюс, он дернут из януса и оттуда же можно дернуть для других БД.
Я бы сказал — это большой минус. Основные жалобы на янус всегда были связаны именно с реструктуризатором. К тому же он вроде бы не понимает всех СУБД которые знакомы БЛТулкиту.
Z>Написать с нуля и протестировать темплейты для всех БД я один не в состоянии.
Снова в качестве аргумента минимизация работы? С этого надо было начинать. Тогда хотя бы было понятно откуда такое упорство.
VD>>Идея очень простая. Ты создаешь некий абстрактный DDL описывающий трансформации сущностей СУБД. Далее ты создаешь базовую группу шаблонов (аналогично классу) где для каждого элемента твоего абстрактного DDL-я имеется шаблон генерирующий текст (прикладной SQL). Этот базовый шаблон генерирует код на некотором диалекте SQL, напирмер, на TSQL. Далее ты (или кто-то другой) создаешь наследников этой группы шаблонов для каждой поддерживаемой СУБД и переопределяешь в нем реализацию тех элементов которые отличаются.
Z>Наконец что-то более менее понятное.
Я уже раза три это весе рассказал на разные лады.
Z>Где доки по всему этому?
Это не какой-то бином ньютона, а просто специализированная версия $-строк.
Собственно $-строки и StringTemplate имеют общую базу. Поддержка ..$() (то есть работы с коллекциями) в $-строках как раз появилась в процессе работы над StringTemplate.
VD>>В таких шаблонах можно будет использовать конкретный синтаксис конкретной СУБД. В том числе можно будет делать проверки наличия констрэйнов и удалять их если нужно (что актуально для MS SQL).
Z>Пока не очень акутально. Констрейнты тоже входят в модель схемы, проверки лучше делать в ней.
Нашел проект реструктуризатора о котором я говорил. Правда он даже не собирается (компонентов не хватает). И не факт, что это самая последняя версия, но поглядеть можно.
Если интересно могу выслать.
Вот код шаблонов генерировавших SQL (DLL).
Базовый шаблон (GeneralTemplate.sql):
group General;
/* Добавляет к имени символы цитирования. Это позвляет именам содержать
* пробельные символы и пересекаться с ключевыми словами
*/
Quot(name) ::= <<
[$name$]
>>
/*
* Преобразование значений в литералы.
*/
StringLiteral(value) ::= <<"$value$">>
AnsiStringLiteral(value) ::= <<"$value$">>
DateTimeLiteral(value) ::= <<"$value$">>
/*****************************************************************************/
/* Генерирует выражение создания индексов.
* name - имя индекса.
* table - имя таблицы для которой требуется осздать индекс.
* type - тип индекса.
* unique - определяет должне ли индекс быть уникальным (булево значение).
* entries - вхождения индекса (мулти-атрибут). Каждое вхождение содержит
* атрибуты: Column - имя колонки, и IsAscending - определяющий
* направление сотрировки (true для прямого и false для обратного).
* Если индекс многоколоночный, то для каждой колнки в entries будет
* содержаться отдельная строка.
*/
CreateIndex(name, table, isClustered, isUnique, entries) ::= <<
/* General:CreateIndex */CREATE $Unique(isUnique)$ $Clustered(isClustered)$ INDEX $Quot(name)$ ON $Quot(table)$
(
$entries:{ entry | $entry.Column$ $Direction(entry.IsAscending)$}; separator=",\n"$
)
>>
/* Выводит сточку "UNIQUE" если isUnique равен true. */Unique(isUnique) ::= <<
$if (isUnique)$ UNIQUE $endif$
>>
Clustered(isClustered) ::= <<
$if (isClustered)$ CLUSTERED$endif$
>>
/* Выводит сточку ASC" если isAscending равен true или "DESC" в обратом случае. */
Direction(isAscending) ::= <<
$if (isAscending)$ASC$else$DESC$endif$
>>
/*****************************************************************************/
/* Генерирует выражение удаления индекса.
* name - имя индекса полдежащего удалению.
* table - имя таблицы индекс которой требуется удалить.
*/
DropIndex(name, table) ::= <<
/* General:DropIndex */DROP INDEX $Quot(name)$ ON $Quot(table)$
>>
/*****************************************************************************/
/* Добавление колонки.
* column - Описание колонки:
* "column.{Name, Type, Nullable, Size, Default, IsVariableSize, IsAutoIncrement}"
*/
/*TODO: Разобраться с "Nullable"! */
CreateColumn(column, table) ::= <<
/* General:CreateColumn */ALTER TABLE $Quot(table)$ ADD $ColumnDefinition(column)$
>>
/* "column.{Name, Type, Nullable, Size, Default, IsVariableSize, IsAutoIncrement}" */
ColumnDefinition(column) ::= <<
$column.Name$ $if (column.IsAutoIncrement)$INTEGER$Nullable(column)$ IDENTITY$else$$TypeDef(column)$$endif$
>>
TypeDef(column) ::= <<
$Type(column)$$Nullable(column)$$column.Default:Default()$
>>
Nullable(column) ::= <<
$if (column.Nullable)$ NULL$else$ NOT NULL$endif$
>>
/* "column.{Name, Type, Nullable, Size, Default, IsVariableSize, IsAutoIncrement}" */
Type(column) ::= <<
$column.Type$$if (column.IsVariableSize)$($column.Size$)$endif$
>>
Default(value) ::= <<
DEFAULT $value$
>>
/*****************************************************************************/
/* A column cannot be dropped when it is (MS SQL):
* Used in an index.
* Used in a CHECK, FOREIGN KEY, UNIQUE, or PRIMARY KEY constraint.
* Associated with a default that is defined with the DEFAULT keyword, or
bound to a default object.
* Bound to a rule.
*/
DropColumn(name, table) ::= <<
/* General:DropColumn */
$DropColumnDefault(table=table, columnName=name)$
ALTER TABLE $Quot(table)$ DROP COLUMN $Quot(name)$
>>
/*****************************************************************************/
CreateTable(name, columns) ::= <<
/* General:CreateTable */CREATE TABLE $Quot(name)$
(
$columns:ColumnDefinition(); separator=",\n"$
)
>>
/*****************************************************************************/
DropTable(name) ::= <<
/* General:DropTable */DROP TABLE $Quot(name)$
>>
/*****************************************************************************/
/* table - Имя таблицы у которой изменена колонка.
* Параметры isXxxChanged имеют тип bool и собщают о том был ли изменено
* то или иное свойство колнки.
*
* У параметров modelColumn и targetColumn имеются следующие свойства:
* Name, Type, Size, Nullable, Default, IsVariableSize, IsAutoIncrement
*/
AlterColumn(table,
isDataTypeChanged, isDefaultChanged, isNullableChanged, isSizeChanged,
isAutoIncrementChanged,
modelColumn, targetColumn) ::=
<<
/* General:AlterColumn */
$!Print_AlterColumn(table=table, isDataTypeChanged=isDataTypeChanged,
isDefaultChanged=isDefaultChanged, isNullableChanged=isNullableChanged,
isSizeChanged=isSizeChanged, isAutoIncrementChanged=isAutoIncrementChanged,
modelColumn=modelColumn, targetColumn=targetColumn)!$
$if (isDefaultChanged)$
$if (modelColumn.Default)$
$AddColumnDefault(table=table, column=modelColumn)$
$else$
$DropColumnDefault(table=table, columnName=targetColumn.Name)$
$endif$
$endif$
$if (isNullableChanged)$$if (!modelColumn.Nullable)$
$MakeUpdate(table=table, modelColumn=modelColumn)$
$endif$$endif$
$if (isDataTypeChanged)$
ALTER TABLE $Quot(table)$ ALTER COLUMN $Quot(targetColumn.Name)$
$Type(modelColumn)$ $Nullable(modelColumn)$ /* isDataTypeChanged */
$else$
$if (isNullableChanged)$
ALTER TABLE $Quot(table)$ ALTER COLUMN $Quot(targetColumn.Name)$
$Type(modelColumn)$ $Nullable(modelColumn)$ /* isNullableChanged */
$endif$
$endif$
>>
MakeUpdate(table, modelColumn) ::= <<
/* General:MakeUpdate modelColumn.Default:$modelColumn.Default$ */
$if (modelColumn.Default)$
UPDATE $Quot(table)$
SET $Quot(modelColumn.Name)$ = $modelColumn.Default$ /* $modelColumn.CliType$ */WHERE $Quot(modelColumn.Name)$ IS NULL
$else$
UPDATE $Quot(table)$
SET $Quot(modelColumn.Name)$ = $DefaultValueForType.(modelColumn.CliType)$ /* $modelColumn.CliType$ */WHERE $Quot(modelColumn.Name)$ IS NULL
$endif$
go
>>
DefaultValueForType ::=
[
"AnsiString" : "''",
"AnsiStringLob" : "''",
"StringLob" : "''",
"String" : "''",
"default" : "0"
]
AlterColumnSetAutoIncrement(table,
isDataTypeChanged, isDefaultChanged, isNullableChanged, isSizeChanged,
isAutoIncrementChanged,
modelColumn, targetColumn) ::=
<<
/* General:AlterColumnSetAutoIncrement */ALTER TABLE $Quot(table)$ DROP COLUMN $Quot(targetColumn.Name)$
go
ALTER TABLE $Quot(table)$ ADD $Quot(modelColumn.Name)$ INTEGER IDENTITY NOT NULL
go
>>
AlterColumnRemoveAutoIncrement(table,
isDataTypeChanged, isDefaultChanged, isNullableChanged, isSizeChanged,
isAutoIncrementChanged,
modelColumn, targetColumn) ::=
<<
Внимание, эта операция специяична для СУБД!
Создайте ее реализацию в специализированном шаблоне!
>>
Print_AlterColumn(table,
isDataTypeChanged, isDefaultChanged, isNullableChanged, isSizeChanged,
isAutoIncrementChanged,
modelColumn, targetColumn) ::=
<<
/*
table = '$table$'
isDataTypeChanged = '$isDataTypeChanged$'
isDefaultChanged = '$isDefaultChanged$'
isNullableChanged = '$isNullableChanged$'
isSizeChanged = '$isSizeChanged$'
isAutoIncrementChanged = '$isAutoIncrementChanged$'
modelColumn.Name = '$modelColumn.Name$'
modelColumn.Type = '$modelColumn.Type$'
modelColumn.Size = '$modelColumn.Size$'
modelColumn.Nullable = '$modelColumn.Nullable$'
modelColumn.Default = '$modelColumn.Default$'
modelColumn.IsVariableSize = '$modelColumn.IsVariableSize$'
modelColumn.IsAutoIncrement = '$modelColumn.IsAutoIncrement$'
targetColumn.Name = '$targetColumn.Name$'
targetColumn.Type = '$targetColumn.Type$'
targetColumn.Size = '$targetColumn.Size$'
targetColumn.Nullable = '$targetColumn.Nullable$'
targetColumn.Default = '$targetColumn.Default$'
targetColumn.IsVariableSize = '$targetColumn.IsVariableSize$'
targetColumn.IsAutoIncrement = '$targetColumn.IsAutoIncrement$'
*/
>>
/*****************************************************************************/
MsSqlServerTemplate.sql:
group MsSqlServer;
/*
* Преобразование значений в литералы.
*/
StringLiteral(value) ::= <<N'$value$'>>
AnsiStringLiteral(value) ::= <<'$value$'>>
DateTimeLiteral(value) ::= <<'$value$'>>
/*****************************************************************************/
AlterColumnRemoveAutoIncrement(table,
isDataTypeChanged, isDefaultChanged, isNullableChanged, isSizeChanged,
isAutoIncrementChanged,
modelColumn, targetColumn) ::=
<<
/* MsSqlServer:AlterColumnRemoveAutoIncrement */EXEC sp_rename '$table$.$targetColumn.Name$', '$targetColumn.Name$_tmp', 'COLUMN'
go
ALTER TABLE $Quot(table)$ ADD $Quot(modelColumn.Name)$ $Type(modelColumn)$ $modelColumn.Default:Default()$
go
UPDATE $Quot(table)$ SET $Quot(modelColumn.Name)$ = $Quot(modelColumn.Name + "_tmp")$
go
$if (modelColumn.Nullable)$
ALTER TABLE $Quot(table)$ ALTER COLUMN $NameTypeAndNullable(modelColumn)$
go
$endif$
ALTER TABLE $Quot(table)$ DROP COLUMN $Quot(modelColumn.Name + "_tmp")$
>>
NameTypeAndNullable(column) ::= <<
$Quot(column.Name)$ $Type(column)$$Nullable(column)$
>>
/*****************************************************************************/
AddColumnDefault(table, column) ::=
<<
$DropColumnDefault(table=table, columnName=column.Name)$
go
ALTER TABLE $Quot(table)$
ADD CONSTRAINT $Quot("DefConstr" + table + column.Name)$
DEFAULT $column.Default$ FOR $Quot(column.Name)$
>>
/*****************************************************************************/
DropColumnDefault(table, columnName) ::=
<<
/* MsSqlServer:DropColumnDefault */
/* Если у колонки существует знчение по умолчанию... */IF Exists(SELECT *
FROM sys.all_columns as cols INNER JOIN sys.default_constraints
ON cols.default_object_id = sys.default_constraints.object_id
WHERE cols.object_id = OBJECT_ID('$table$')
AND cols.name = '$columnName$')
BEGIN
DECLARE @constraintName SYSNAME
/* Определяем его имя */SELECT @constraintName = sys.default_constraints.name
FROM sys.all_columns as cols INNER JOIN sys.default_constraints
ON cols.default_object_id = sys.default_constraints.object_id
WHERE cols.object_id = OBJECT_ID('$table$')
AND cols.name = '$columnName$'
/* Удаляем ограничение. */EXEC('ALTER TABLE $Quot(table)$ DROP CONSTRAINT [' + @constraintName + ']');
/*PRINT 'Огнаничение ' + @constraintName + ' удалено!'*/END
>>
MsJetTemplate.sql:
group MsJet;
AlterColumnRemoveAutoIncrement(table,
isDataTypeChanged, isDefaultChanged, isNullableChanged, isSizeChanged,
isAutoIncrementChanged,
modelColumn, targetColumn) ::=
<<
/* MsJet:AlterColumnRemoveAutoIncrement */
$AlterColumn(table=table, isDataTypeChanged=isDataTypeChanged,
isDefaultChanged=isDefaultChanged, isNullableChanged=isNullableChanged,
isSizeChanged=isSizeChanged, isAutoIncrementChanged=isAutoIncrementChanged,
modelColumn=modelColumn, targetColumn=targetColumn)$
>>
/*****************************************************************************/
AddColumnDefault(table, column) ::=
<<
/* MsJet:AddColumnDefault */ALTER TABLE $Quot(table)$
ALTER COLUMN $Quot(column.Name)$ SET DEFAULT $column.Default$;
go
UPDATE $Quot(table)$
SET $Quot(column.Name)$ = $column.Default$
WHERE $Quot(column.Name)$ IS NULL
go
>>
/*****************************************************************************/
DropColumnDefault(table, columnName) ::=
<<
/* MsJet:DropColumnDefault */ALTER TABLE $Quot(table)$ ALTER COLUMN $Quot(columnName)$ DROP DEFAULT;
>>
/*****************************************************************************/Clustered(isClustered) ::= <<
/* CLUSTERED */
>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Проект NRails.Demo валится:
Doctor.n(8,6):Error: Doctor model error: System.Data.SqlClient.SqlException: Cannot open database "NRailsDemo" requested by the login. The login failed.
Попробовал создать БД с помощью VS (у меня MS SQL Express поставленный 2010-ой студией), но она выдает сообщение об ошибке при попытке проверить соединение выдает:
---------------------------
Microsoft Visual Studio
---------------------------
A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 — Could not open a connection to SQL Server)
---------------------------
ОК
---------------------------
Утилит к экспрессу никаких нет, так что не ясно что делать.
Ну, и второй вопрос. Твои миграции саму БД будут создавать? Или БД всегда надо вручную создавать?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Попробовал собрать солюшен.
VD>Проект NRails.Demo валится: VD>Doctor.n(8,6):Error: Doctor model error: System.Data.SqlClient.SqlException: Cannot open database "NRailsDemo" requested by the login. The login failed.
Верно, ему для сборки нужна корректная БД. Для корректной БД нужна собранная NRails.Demo.Migrations и NRails.Console. Надо научиться компилировать миграции в памяти, без msbuild, тогда не нужен будет отдельный проект.
VD>Ну, и второй вопрос. Твои миграции саму БД будут создавать? Или БД всегда надо вручную создавать?
Надо просто запустить migrate.cmd из NRials.Demo, она создаст базу и нужные таблицы.
Здравствуйте, Ziaw, Вы писали:
Z>Верно, ему для сборки нужна корректная БД. Для корректной БД нужна собранная NRails.Demo.Migrations и NRails.Console. Надо научиться компилировать миграции в памяти, без msbuild, тогда не нужен будет отдельный проект.
Да фиг бы с ним с проектом. Пускай будет. Просто логично было бы всю начальную инициализацию делать из этого проекта.
VD>>Ну, и второй вопрос. Твои миграции саму БД будут создавать? Или БД всегда надо вручную создавать?
Z>Надо просто запустить migrate.cmd из NRials.Demo, она создаст базу и нужные таблицы.
Хм. Действительно помогло (только работало не быстро).
А нельзя ли их было в проект как пребилд-шаг воткнуть?
И что за странные ворнинги при сборке NRails.Demo?
Здравствуйте, VladD2, Вы писали:
VD>Главное здесь, то что шаблон (то что выглядит как функция) переопределяет (override, выделено жирным) шаблон объявленный в базовой группе шаблонов. VD>Пользователь может заменить этот шаблон, но не может налепить черти чего.
Все таки наследование. Т.е. ST это просто чуть более удобный способ форматировать строки.
VD>Глупость не говори. Попробуй на досуге посимвольно конкатенировать строки. Увидишь, что даже на небольших строках начнутся тормоза, так как это экспонента.
Все эти тормоза на порядки быстрее выполнения команды которая в результате получилась. Выиграть <1% в некритичной по скорости операции?
Z>>У меня вполне читаемый sql получается. Конечно не идеально отформатированный, но для чтения человеком вполне достаточно.
VD>Читаемый без отступов? У нас видимо диаметрально противоположенные понятия о читаемости. VD>А зачем не идеальный, когда можно получить идеально отформатированный код? VD>В общем, "упорству храбрых поем мы песню...". Через зад но по-своему.
CREATE TABLE [SchemaMigrations] ([Version] NVARCHAR(255) NOT NULL,
PRIMARY KEY ([Version]))
CREATE TABLE [Person] ([PersonID] INT IDENTITY (1,1) NOT NULL,
[FirstName] NVARCHAR(50) NOT NULL,
[LastName] NVARCHAR(50) NOT NULL,
[MiddleName] NVARCHAR(50),
[Gender] NCHAR(1) NOT NULL,
PRIMARY KEY ([PersonID]))
CREATE TABLE [Doctor] ([PersonID] INT NOT NULL,
[Taxonomy] NVARCHAR(50) NOT NULL,
)
CREATE TABLE [Patient] ([PersonID] INT NOT NULL,
[Diagnosis] NVARCHAR(256) NOT NULL,
)
Я тебя правильно понимаю, что читабельность отсутствует и требуется переписать драйвер с нуля ради этого?
Z>>Кидаться переписывать драйвер БД изза них я не буду.
VD>У... В нашем деле — это никудышная позиция. Я порой переписываю код по 5 раз только для того чтобы удовлетворить свое чувство прекрасного. Ты делаешь то, что до тебя никто не делал, так что эксперименты — это главный способ выбора лучших решений.
Я тоже переписываю код по тем же причинам. Но ресурсы не резиновые, я предпочту экспериментировать и полировать view engine, чем переписывать драйвер схемы БД ради идеальных отступов.
VD>Ведь у тебя еще не готовы драйверы для всех поддерживаемых БЛТулкитом СУБД?
Нет, но они есть в янусе.
VD>Найти в коде проекта код связанный с драйверами было очень не просто.
NRails.Database.Schema
NRails.Database.Mssql
Это было найти сложно?
VD>Ты конечно снова можешь не слушать моих советов, но я бы посоветовал не сваливать в один файл кучу классов, даже если каждый из них очень маленький. Ни компилятор, ни IDE не напряжет если ты разложишь типы отдельные файлы. А вот люди будут ориентироваться в коде намного проще.
Тут согласен. Я поправлю эти файлы, как только миграции будут более менее готовы, пока это способ не держать в студии десятки открытых файлов. Очень не хватает навигации решарпера
VD>Кстати, зачем было выбирать Меркури в качестве сорс-контрола? У меня на машине даже нечем скачать код. VD>Пришлось тратить время на поиск и установку клиента. VD>SVN вроде бы вполне приемлем для открытых проектов и его криент есть почти у всех. Тем самым ты сужаешь аудиторию.
hg давно один из стандартных VCS при открытой разработке. Поработав с ним на svn только за деньги работать хочется.
VD>Я бы сказал — это большой минус. Основные жалобы на янус всегда были связаны именно с реструктуризатором. К тому же он вроде бы не понимает всех СУБД которые знакомы БЛТулкиту.
А реструктуризатор мне как раз и не нужен, нужен код который был написан для него.
Z>>Написать с нуля и протестировать темплейты для всех БД я один не в состоянии.
VD>Снова в качестве аргумента минимизация работы? С этого надо было начинать. Тогда хотя бы было понятно откуда такое упорство.
Это основной аргумент в минус. Все остальное — попытки понять плюсы, единственный понятый это возможность идеально отформатировать SQL. Что достигается и другими средствами, гораздо проще чем переписывать все.
VD>>>Идея очень простая. Ты создаешь некий абстрактный DDL описывающий трансформации сущностей СУБД. Далее ты создаешь базовую группу шаблонов (аналогично классу) где для каждого элемента твоего абстрактного DDL-я имеется шаблон генерирующий текст (прикладной SQL). Этот базовый шаблон генерирует код на некотором диалекте SQL, напирмер, на TSQL. Далее ты (или кто-то другой) создаешь наследников этой группы шаблонов для каждой поддерживаемой СУБД и переопределяешь в нем реализацию тех элементов которые отличаются.
VD>Не так давно, ты утверждал, что проверки очень нужды . Ну, да пока не надо — это тоже никудышный аргумент. Если проект дойдет до серьезного использования, то сложного SQL-я будет выше крыши.
Я не утверждал, что они нужны на каждом диалекте сиквела.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Ziaw, Вы писали:
Z>>Верно, ему для сборки нужна корректная БД. Для корректной БД нужна собранная NRails.Demo.Migrations и NRails.Console. Надо научиться компилировать миграции в памяти, без msbuild, тогда не нужен будет отдельный проект.
VD>Да фиг бы с ним с проектом. Пускай будет. Просто логично было бы всю начальную инициализацию делать из этого проекта.
Хочется такого: выкачиваешь один проект, запускаешь миграцию, открываешь солюшен.
VD>>>Ну, и второй вопрос. Твои миграции саму БД будут создавать? Или БД всегда надо вручную создавать?
Z>>Надо просто запустить migrate.cmd из NRials.Demo, она создаст базу и нужные таблицы.
VD>Хм. Действительно помогло (только работало не быстро).
Ну базу надо создать. Еще тормоза в том, что я после каждого изменения перечитываю схему таблицы.
VD>А нельзя ли их было в проект как пребилд-шаг воткнуть?
Нельзя, это совсем не прибилд шаг.
VD>И что за странные ворнинги при сборке NRails.Demo? VD>
Здравствуйте, Ziaw, Вы писали:
VD>>Да фиг бы с ним с проектом. Пускай будет. Просто логично было бы всю начальную инициализацию делать из этого проекта.
Z>Хочется такого: выкачиваешь один проект, запускаешь миграцию, открываешь солюшен.
Отдельный то проект зачем?
Z>Ну базу надо создать. Еще тормоза в том, что я после каждого изменения перечитываю схему таблицы.
Зачем? Эдак на реальной БД придется ждать по часу.
VD>>А нельзя ли их было в проект как пребилд-шаг воткнуть?
Z>Нельзя, это совсем не прибилд шаг.
Почему?
Z>Насчет первых двух сам не знаю, надеюсь, что они исчезнут, когда переведу на шаблон MVC из сборки nemerle. Если нет надо будет копать.
Судя по описания два раза подключаются стандартные библиотеки. Возможно в проекте выключен NoStdLib и при этом ссылки на стандартные сборки прописаны вручную. Или прописаны дважды.
Z>А последние — эксперимент, попытка сделать тултипы для атрибутных макров Наведи мышку на [Model] в Doctor.n.
Нда...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>>>Да фиг бы с ним с проектом. Пускай будет. Просто логично было бы всю начальную инициализацию делать из этого проекта.
Z>>Хочется такого: выкачиваешь один проект, запускаешь миграцию, открываешь солюшен.
VD>Отдельный то проект зачем?
Не отдельный, а именно один проект над которым ты работаешь, в данном случае NRails.Demo.
Z>>Ну базу надо создать. Еще тормоза в том, что я после каждого изменения перечитываю схему таблицы.
VD>Зачем? Эдак на реальной БД придется ждать по часу.
Почему по часу? Это же инкрементальные изменения. Да и с нуля, для часа надо примерно 3600 изменений таблиц, это сильно большой проект. Для него и час на развертывание БД не самая большая проблема. Сделано это затем, чтобы подхватить изменения ключей и констрейнтов неявно создаваемых СУБД. Действительно ускорить это можно только отказом от работы с имеющейся схемой, что сильно усложнит логику мигратора и драйверов для каждой БД. Но схему все равно придется читать для каждого билда проекта, который выполняется гораздо чаще выполнения миграций. Думаю еще оптимизация читателя схемы даст хороший плюс, там есть над чем поработать.
VD>>>А нельзя ли их было в проект как пребилд-шаг воткнуть?
Z>>Нельзя, это совсем не прибилд шаг.
VD>Почему?
Потому, что изменение схемы должно быть сознательным действием, а не неявным.
Z>>Насчет первых двух сам не знаю, надеюсь, что они исчезнут, когда переведу на шаблон MVC из сборки nemerle. Если нет надо будет копать.
VD>Судя по описания два раза подключаются стандартные библиотеки. Возможно в проекте выключен NoStdLib и при этом ссылки на стандартные сборки прописаны вручную. Или прописаны дважды.
Вобщем это локальные проблемы данного проекта, я его все равно поменяю скоро.
Z>>А последние — эксперимент, попытка сделать тултипы для атрибутных макров Наведи мышку на [Model] в Doctor.n.
VD>Нда...
я уже видел эти ворнинги, наверное уберу хинты. Чем их заменить?
Здравствуйте, VladD2, Вы писали:
VD>Зачем? Эдак на реальной БД придется ждать по часу.
Вобщем, как обычно, преждевременная оптимизация.
[12:15:33.075] begin migrations
[12:15:33.716] database created
[12:15:38.325] new database connected <-- тормоз тут, создается база, я ни при чем
[12:15:38.544] schema loaded
[12:15:38.544] Start migration '!init!'
[12:15:38.560] CREATE TABLE [SchemaMigrations] (
[Version] NVARCHAR(255) NOT NULL,
PRIMARY KEY ([Version]))
[12:15:38.982] Finish migration '!init!'
[12:15:38.982] Start migration '000000'
[12:15:38.982] CREATE TABLE [Person] (
[PersonID] INT IDENTITY (1,1) NOT NULL,
[FirstName] NVARCHAR(50) NOT NULL,
[LastName] NVARCHAR(50) NOT NULL,
[MiddleName] NVARCHAR(50),
[Gender] NCHAR(1) NOT NULL,
PRIMARY KEY ([PersonID]))
[12:15:38.997] CREATE TABLE [Doctor] (
[PersonID] INT NOT NULL,
[Taxonomy] NVARCHAR(50) NOT NULL,
PRIMARY KEY ([PersonID]))
[12:15:38.997] CREATE TABLE [Patient] (
[PersonID] INT NOT NULL,
[Diagnosis] NVARCHAR(256) NOT NULL,
)
[12:15:39.153] insert migration info 000000
[12:15:39.403] migration info inserted <--- тормоз тут, похоже тулкит генерит мапперы для работы с базой, это будет тормозить только один раз на запуск
[12:15:39.403] Finish migration '000000'
[12:15:39.403] end migrations
Если база создана, миграция отрабатывает очень бодро, чуть более секунды, основное это начальное чтение схемы (100-200мс) и тулкит (250мс), имхо, вполне приемлемое время. Надо будет потестить потом как будет расти время чтения схемы в зависимости от количества таблиц в ней.
Здравствуйте, Ziaw, Вы писали:
VD>>Зачем? Эдак на реальной БД придется ждать по часу.
Z>Вобщем, как обычно, преждевременная оптимизация.
На вопрос ты так и не ответил.
Z>Если база создана, миграция отрабатывает очень бодро, чуть более секунды, основное это начальное чтение схемы (100-200мс) и тулкит (250мс), имхо, вполне приемлемое время. Надо будет потестить потом как будет расти время чтения схемы в зависимости от количества таблиц в ней.
Пока все ОК. Поглядим что будет когда база вырастет хотя бы до среднего уровня.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Ziaw, Вы писали:
VD>>>Зачем? Эдак на реальной БД придется ждать по часу.
Z>>Вобщем, как обычно, преждевременная оптимизация.
VD>На вопрос ты так и не ответил.
Сделано это затем, чтобы подхватить изменения ключей и констрейнтов неявно создаваемых СУБД. Действительно ускорить это можно только отказом от работы с имеющейся схемой, что сильно усложнит логику мигратора и драйверов для каждой БД. Но схему все равно придется читать для каждого билда проекта, который выполняется гораздо чаще выполнения миграций. Думаю еще оптимизация читателя схемы даст хороший плюс, там есть над чем поработать.
Перечитывается схема одной таблицы, время тут слабо зависит от размера БД.
на гуглкоде. В проекте NRails.Demo есть файлик migrate.cmd, правда он еще не умеет компилить миграции, NRails.Demo.Migrations надо сбилдить руками.
. Ну, да пока не надо — это тоже никудышный аргумент. Если проект дойдет до серьезного использования, то сложного SQL-я будет выше крыши.
я уже видел эти ворнинги, наверное уберу хинты. Чем их заменить?
