Разве "проверить конвертируемость на cast, для всех записей (fetchall)" это не есть то же самое, только выполненное ручками? При создании/пересоздании PK/FK/UnqIdx происходит то же самое "прочесывание" и тоже с вероятностью отлупа. В случае нарушений каких-либо условий - сервер отказывает с указанием причины. Тут полная аналогия.kdv писал(а):вернее, теоретически может, но с учетом вероятности отлупа и вероятности прочесывания больших объемов данных, я бы не идеализировал возможность возложения этих задач на сервер.
FB 2.0.3. consistency check при создании индекса
я и имел в виду про "ручки". Ключевое слово перед списком "вы сами должны"."проверить конвертируемость на cast, для всех записей (fetchall)" это не есть то же самое, только выполненное ручками?
допустим. ты предлагаешь серверу проверять валидность alter table alter column путем создания индекса, втихаря?При создании/пересоздании PK/FK/UnqIdx происходит то же самое "прочесывание" и тоже с вероятностью отлупа.
я еще раз напоминаю, что средний размер баз нынче 2-20 гиг. И если ты меняешь тип столбца, то ты сам должен думать, что из этого должно получиться.[/quote]
Уточню.
Дано:
Смена домена для поля через ALTER TABLE ALTER COLUMN. Есть ограничение - нельзя менять на домен с меньшей разрядности (Integer -> SmallInt, Varchar(10) -> Varchar(9)) из-за возможной потери данных.
Задача: смена на тип меньшей разрядности.
Решение: перед сменой домена проверка записей на допустимость значений новой разрядности.
Аргументы против: посторонние транзакции, сборка мусора, необходимость проверки конвертируемости, возможный отлуп и большие объемы данных.
Два тезиса:
1. Допускается смена домена в сторону большей разрядности. Это вполне обычное действие.
2. Перед созданием PK/FK/UnqIdx сервер сначала проверяет значения записей путем считывания их всех. В случае отрицательной проверки - отказ. Если таблица используется - отказ. Это тоже обычное действие.
И ведь никто не задается вопросами: а сколько там у меня версий записей, как долго будет выполняться операция и пр.? Так же в некоторых случаях нет уверенности, что операция завершится успешно (например, если спустя год работы БД решили добавить UnqIdx на поле "Имя улицы" или поле используется в индексе). То есть поведение сервера в п. 1-2 - это нормальный режим работы.
Тогда почему объединение функциональности п. 1 (смена домена поля) и части функциональности п.2 (чтение всех записей для проверки и монопольный доступ к таблице для применения изменений) считаете недопустимым, используя вышеприведенные аргументы против?
Дано:
Смена домена для поля через ALTER TABLE ALTER COLUMN. Есть ограничение - нельзя менять на домен с меньшей разрядности (Integer -> SmallInt, Varchar(10) -> Varchar(9)) из-за возможной потери данных.
Задача: смена на тип меньшей разрядности.
Решение: перед сменой домена проверка записей на допустимость значений новой разрядности.
Аргументы против: посторонние транзакции, сборка мусора, необходимость проверки конвертируемости, возможный отлуп и большие объемы данных.
Два тезиса:
1. Допускается смена домена в сторону большей разрядности. Это вполне обычное действие.
2. Перед созданием PK/FK/UnqIdx сервер сначала проверяет значения записей путем считывания их всех. В случае отрицательной проверки - отказ. Если таблица используется - отказ. Это тоже обычное действие.
И ведь никто не задается вопросами: а сколько там у меня версий записей, как долго будет выполняться операция и пр.? Так же в некоторых случаях нет уверенности, что операция завершится успешно (например, если спустя год работы БД решили добавить UnqIdx на поле "Имя улицы" или поле используется в индексе). То есть поведение сервера в п. 1-2 - это нормальный режим работы.
Тогда почему объединение функциональности п. 1 (смена домена поля) и части функциональности п.2 (чтение всех записей для проверки и монопольный доступ к таблице для применения изменений) считаете недопустимым, используя вышеприведенные аргументы против?
нихера он не проверяет. он СТРОИТ индекс. и уже неуспешное создание индекса сигнализирует о проблемах в значении столбца (дубликаты или нет правильной ссылки по ФК.Перед созданием PK/FK/UnqIdx сервер сначала проверяет значения записей путем считывания их всех
это ты не задаешься вопросом. я никак не пойму, почему надо курочить метаданные вместо того чтобы сначала ПРОВЕРИТЬ руками, допустимо-ли такое преобразование, и самому найти где проблемы?И ведь никто не задается вопросами
если ты считаешь, что разрабочикам нечем заняться - давай их загрузим именно этим. Охрененная будет фича, все будут хлопать в ладоши и радоваться.Тогда почему объединение функциональности п. 1 (смена домена поля) и части функциональности п.2 (чтение всех записей для проверки и монопольный доступ к таблице для применения изменений) считаете недопустимым, используя вышеприведенные аргументы против?
Сути это не меняет. В любом случае для достижения цели надо считать все записи и это нормально.kdv писал(а):нихера он не проверяет. он СТРОИТ индекс. и уже неуспешное создание индекса сигнализирует о проблемах в значении столбца (дубликаты или нет правильной ссылки по ФК.
В том то и дело, что я не хочу курочить данные. Пример (гипотетический): у меня в таблице столбец varchar(1000). Оказалось, что не надо допускать столько символов, достаточно 10. Проверяю - весь миллион записей не выходят за границы 10 символов. А дальше что?kdv писал(а):это ты не задаешься вопросом. я никак не пойму, почему надо курочить метаданные вместо того чтобы сначала ПРОВЕРИТЬ руками, допустимо-ли такое преобразование, и самому найти где проблемы?
Вариант 1: создать второй столбец, копировать в него данные (миллион новых версий), удалить первый столбец и переименовывать второй. То бишь, целый набор действий.
Вариант 2: хакнуть систаблицу (если я не ошибаюсь, только так IBE меняет домен поля) и одной командой получить требуемый результат. Ну а после всех манипуляций с доменами (допустим, их больше сотни) b/r для профилактики. Причем, судя по всему, это проходит без фатальных побочных эффектов. А, нет, есть один - если поленился и не сделал проверку, получаем сабжевую ошибку. Что лечится легко: меняем домен как был, переконнект, поиск проблемных строк и снова изменение.
Ввиду тотального использования IBE в качестве инструментария, получается, что большинство пользователей используют вариант 2 (в том числе и я).
Я лишь озвучил проблему со сменой домена поля. Ее решение сделало бы возможным сделать эту смену всегда через Alter Column (судя по Борри, это единственное ограничение), за что я только "ЗА".kdv писал(а):если ты считаешь, что разрабочикам нечем заняться - давай их загрузим именно этим. Охрененная будет фича, все будут хлопать в ладоши и радоваться.
Повесить CHECK на это поле и не морочить головуCyberMax писал(а):В том то и дело, что я не хочу курочить данные. Пример (гипотетический): у меня в таблице столбец varchar(1000). Оказалось, что не надо допускать столько символов, достаточно 10. Проверяю - весь миллион записей не выходят за границы 10 символов. А дальше что?
фиг там. если бы это было изменение типа с varchar на integer, то ты бы жестоко обломился. Выучи сначала версионность метаданных.то лечится легко: меняем домен как был, переконнект, поиск проблемных строк и снова изменение.
http://www.ibase.ru/devinfo/metaver.htm
Пардон, забыл уточнить в предыдущем посте, что сабж только при создании индекса. При просмотре таблицы - исключение преобразования, которое не влияет на дальнейшую работу сервера.
Это шутка такая?hvlad писал(а):Повесить CHECK на это поле и не морочить голову
Создал таблицу c полем id varchar(10). вставил три записи - '1', '2a' и '3'. Сменил домен на Integer. При открытии таблицы сервер запнулся на второй записи. Сменил домен обратно на строковый, переконнектился и исправил вторую запись. Опять смена домена, переконнект и просмотр таблицы - все ОК. Где облом?kdv писал(а):фиг там. если бы это было изменение типа с varchar на integer, то ты бы жестоко обломился. Выучи сначала версионность метаданных.
Выяснились следующие моменты:
1. На работе (FB 2.0.3) ситуация не воспроизвелась. Сервер запрещает изменение домена как через ALTER TABLE, так и через правку RDB$RELATION_FIELDS. Что стоит дома (где я проверял), уточню позже, а заодно попробую вопроизвести тест.
2. При изменении домена через редактирование структуры таблицы, IBE использует ALTER TABLE, а при изменении домена через редактирование поля - лезет в RDB$RELATION_FIELDS.
1. На работе (FB 2.0.3) ситуация не воспроизвелась. Сервер запрещает изменение домена как через ALTER TABLE, так и через правку RDB$RELATION_FIELDS. Что стоит дома (где я проверял), уточню позже, а заодно попробую вопроизвести тест.
2. При изменении домена через редактирование структуры таблицы, IBE использует ALTER TABLE, а при изменении домена через редактирование поля - лезет в RDB$RELATION_FIELDS.
раньше вроде сервер преобразовывал последовательно по форматам. поэтому второй альтер к исходному типу столбца не работал.Результат положительный, то есть на обратную смену сервер не ругается. Не понимаю.
сейчас возможно работает иначе, завтра утром у Влада очно спрошу (мы оба в Варшаве, на семинаре)