<commit_before># Создание миграций

Миграции - это классы .NET, в коде которых описаны изменения БД с помощью специального API. Классы компилируются в файл `.dll`, имея который, можно применить изменения для конкретной БД. 

Миграции наследуются от абстрактного базового класса `ThinkingHome.Migrator.Framework.Migration` и реализуют его абстрактный метод `Apply`. В этом методе находится описание всех нужных имзменений БД. Также в миграциях можно переопределить виртуальный метод `Revert` базового класса. Там можно описать действия для отката изменений миграции. Например, если в методе `Apply` была создана новая таблица, то в методе `Revert` можно её удалить. 

### Контроль версий

Для каждой миграции нужно указать номер версии, в которую перейдет БД после применения изменений миграции. Для этого нужно отметить класс миграции атрибутом `[Migration]` и указать номер версии как его параметр.

```c#
using ThinkingHome.Migrator.Framework;

[Migration(12)]
public class MyTestMigration : Migration
{
   // ...
}
```

Номер версии - это целое число (`long`). Можно указывать любое значение на свой выбор, например, порядковый номер или timestamp (временную метку). Главное - помнить, что миграции с меньшим номером будут выполнены раньше, чем миграции с бо́льшим номером.

Если в миграциях реализован метод `Revert`, то можно обновить БД до версии, ниже текущей - миграции будут выполнены в обратном порядке.




### SchemaQualifiedObjectName

### Типы столбцов

### Условные операции

```c#
IConditionByProvider ConditionalExecuteAction();
```
<commit_msg>описание параллельного версионирования и названий объектов БД со схемами<commit_after># Создание миграций

Миграции - это классы .NET, в коде которых описаны изменения БД с помощью специального API. Классы компилируются в файл `.dll`, имея который, можно применить изменения для конкретной БД. 

Миграции наследуются от абстрактного базового класса `ThinkingHome.Migrator.Framework.Migration` и реализуют его абстрактный метод `Apply`. В этом методе находится описание всех нужных имзменений БД. Также в миграциях можно переопределить виртуальный метод `Revert` базового класса. Там можно описать действия для отката изменений миграции. Например, если в методе `Apply` была создана новая таблица, то в методе `Revert` можно её удалить. 

### Контроль версий

Для каждой миграции нужно указать номер версии, в которую перейдет БД после применения изменений. Для этого нужно отметить класс миграции атрибутом `[Migration]` и указать номер версии как его параметр.

```c#
using ThinkingHome.Migrator.Framework;

[Migration(12)]
public class MyTestMigration : Migration
{
   // ...
}
```

Номер версии - это целое число (`long`). Можно указывать любое значение на свой выбор, например, порядковый номер или timestamp (временную метку). Главное - помнить, что миграции с меньшим номером будут выполнены раньше, чем миграции с бо́льшим номером.

Если в миграциях реализован метод `Revert`, то можно обновить БД до версии, ниже текущей - миграции будут выполнены в обратном порядке.

### Параллельное версионирование

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

При выполнении миграций информация о них записывается в специальную таблицу в БД. Кроме версии миграции туда записывается идентификатор сборки, в которой она находится. По умолчанию он совпадает с именем файла `.dll`. При запуске мигратор строит план выполнения - список миграций, которые нужно выполнить, чтобы перевести БД из текущей версии в нужную. При построении плана учитываются только те миграции, идентификатор сборки которых совпадает с текущим `.dll` файлом.

Если вам нужно, чтобы у миграций из нескольких файлов был одинаковый идентификатор сборки, отметьте каждый файл `.dll` атрибутом `[MigrationAssembly]`, передав им в качестве аргумента одинаковое значение.

```c#
[assembly: MigrationAssembly("my-key")]
```

### Названия объектов БД

При описании изменений БД часто нужно ссылаться на объекты БД (таблицы, столбцы, индексы и т.д.) по имени. Имя может включать название схемы БД, к которой относится объект.

Для работы с названиями объектов БД в пакете `ThinkingHome.Migrator.Framework` описан специальный класс `SchemaQualifiedObjectName`. У него есть два поля: `Name` — название объекта БД и `Schema` — название схемы (может быть пустым). Многие методы API мигратора принимают аргументы с типом `SchemaQualifiedObjectName`. 

Чтобы было удобно работать с именами объектов БД, сделано автоматическое приведение типов `string` → `SchemaQualifiedObjectName`. Следующие две команды — эквивалентны:

```c#
// удаление таблицы "my_table"
Database.RemoveTable(new SchemaQualifiedObjectName { Name = "my_table" });

// удаление таблицы "my_table"
Database.RemoveTable("my_table");
```

Если нужно указать название схемы, используйте extension method `WithSchema` класса `string`. Следующие записи — эквивалентны:

```c#
// удаление таблицы "test.my_table"
Database.RemoveTable(new SchemaQualifiedObjectName { Name = "my_table", Schema = "test" });

// удаление таблицы "test.my_table"
Database.RemoveTable("my_table".WithSchema("test"));
``` 

### Типы столбцов

### Условные операции

```c#
IConditionByProvider ConditionalExecuteAction();
```

{'fraction_non_alphanumeric': 0.07068645640074211, 'fraction_numerical': 0.0007421150278293135, 'mean_word_length': 5.379881656804733, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '7027511', 'n_tokens_mistral': 2073, 'n_tokens_neox': 2503, 'n_words': 647}