Господа, никто не подскажет - можно ли временно заблокировать изменение представления при переименовании поля в таблице?

Dima T, чтение тут абсолютно ни при чем. Мне нужен скрипт, который изменяет параметры поля (например, тип или длину). У SQLite нет конструкции Alter Table Modify, поэтому мне нужно переименовать старое поле, добавить новое, скопировать данные из старого в новое и затем старое удалить. Но в момент переименования старого поля оно переименовывается также и во вьюхе. Мне нужно как-то заблокировать изменение вьюхи. Транзакция тут совершенно не помогает. Некорректная операция все равно вызывает ошибку, независимо от того, в рамках транзакции оно происходит или нет

little-brother, спасибо, но, к сожалению, не то. Скрипт отрабатывает без ошибок, но представление меняется и после, естественно не работает

Dima T,

-- Отключаем использование внешних ключей
PRAGMA foreign_keys = 0;

-- Переименовываем имеющееся поле
Alter Table `tbListVars` Rename Column `vcParentString` To `vcParentString_Old`;

-- Добавляем поле
Alter Table `tbListVars` Add `vcParentString` VarChar(1000) Default '…' Not Null;

-- Копируем данные в новое поле
Update `tbListVars` Set `vcParentString` = `vcParentString_Old`;

-- Удаляем старое поле
Alter Table `tbListVars` Drop Column `vcParentString_Old`;

-- Включаем использование внешних ключей
PRAGMA foreign_keys = 1;

Вот мой скрипт. Где именно я тут обращаюсь к представлению? Изменение идет в конкретной таблице. Но в тот момент, когда я переименовываю поле в таблице, в представлении это поле тоже переименовывается. Вполне возможно, что вьюха вида "Select * From `tbListVars`" не пострадает. Но меня такие вьюхи не устраивают, в моих необходимые поля перечисляются конкретно

Dima T, это до переименования поля в таблице

Dima T, а это после

Dima T, вот-вот. Причем сохранять скрипт вьюхи перед изменением таблицы, убивать ее, потом менять поле и только тогда создавать вьюху заново. Странно, что нет более простого способа. Жаль, конечно...

Dima T, насчет триггеров не знаю, а с индексами проблем нет. Когда вьюхи на таблицу не существует, весь скрипт прекрасно выполняется. Индексы он обязан перестраивать при изменении таблицы

Dima T, да, я, видимо, игрался с полями, по которым индексы не построены. В общем, сплошной гемор

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

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

little-brother,

https://runebook.dev/ru/docs/sqlite/pragma#pragma_legacy_alter_table

"PRAGMA legacy_alter_table;
PRAGMA legacy_alter_table = логическое

Эта прагма устанавливает или запрашивает значение флага legacy_alter_table. Когда этот флаг установлен, команда ALTER TABLE RENAME (для изменения имени таблицы) работает так же, как в SQLite 3.24.0 (2018-06-04) и ранее. Более конкретно, когда этот флаг установлен, команда ALTER TABLE RENAME перезаписывает только начальное вхождение имени таблицы в своем операторе CREATE TABLE и во всех связанных операторах CREATE INDEX и CREATE TRIGGER . Другие ссылки на таблицу без изменений, в том числе:

Ссылки на таблицу в телах триггеров и представлений.
Ссылки на таблицу в пределах ограничений CHECK в первоначальном заявлении CREATE TABLE.
Ссылки на таблицу в разделах WHERE частичных индексов ."

Триггера в блоке Create она все-таки ломает

little-brother, представления надо убивать, только если имя поля меняется. Иначе все прекрасно живет. А вот индексы надо дропать точно, потому как имена индексов - особенно автоматические, если создавать неименованный индекс - не привязаны к имени таблицы, соответственно вряд ли они изменятся от переименования таблицы. Отсюда вытекает два постулата: 1 - желательно делать именованные индексы; 2 - перед созданием индекса лучше всего делать Drop Index If Exists

little-brother, извиняюсь, оказывается соврал. Неименованные индексы привязаны к имени таблицы и переименовываются при переименовании самой таблицы. Первичный ключ для таблицы `tbListVars` получает автоматом наименование sqlite_master_PK_tbListVars, при переименовании таблицы в `tbListVars_Old` он становится sqlite_master_PK_tbListVars_Old. Так что, все еще более упростилось (в том смысле, что убивать индексы не надо). Да, свою задачу я решил. Переименовываю нужную таблицу, создаю новую (для начала без индексов), переношу данные из старой в новую, удаляю старую (все старые индексы при этом убиваются сами) и снова создаю все индексы уже на новую таблицу. После pragma legacy_alter_table = 0; пробую прочитать данные из вьюхи - все работает (естественно, при условии, что у изменяемого поля не меняется наименование)

Я говорил про имена индексов. В DDL для индекса что имя его самого, что имя таблицы обязательны, но можно написать:

`iID` Integer Unsigned Default 0 Not Null Constraint `pkListVars_ID` Primary Key,
`iParentID` Integer Unsigned Default 0 Not Null Constraint `fkListVars_ParentID` References `tbListVars`(`iID`) On Delete Cascade,

а можно:
`iID` Integer Unsigned Default 0 Not Null Primary Key,
`iParentID` Integer Unsigned Default 0 Not Null References `tbListVars`(`iID`) On Delete Cascade,

Во втором случае индексы получат наименование автоматически. Соответственно, можно при создании новой таблицы сразу создавать все индексы, предварительно убивая существующие. А можно сначала удалить старую таблицу, и только потом навесить индексы на новую. Видимо, в данном случае удобнее этот вариант

little-brother, экспериментальным путем выяснилось, что первичные и внешние ключи вообще плюют на задаваемое в конструкции Constraint имя и всегда именуются автоматически. Ошибки при этом не возникает, выражение Constraint [index_name] просто игнорируется