iBase.ru Forum

Возможно, данный случай есть в трекере.
Таблица: Запись: Меняем длину поля NAME c 50 до 10 символов. При открытии таблицы сервер пишет о переполнении (что естественно), а при создании индекса по полю NAME:
"internal gds software consistency check (can't continue after bugcheck).".

CyberMax писал(а):Возможно, данный случай есть в трекере.
Таблица:

Код: Выделить всё

CREATE TABLE SOME_TABLE (
    ID    INTEGER NOT NULL,
    NAME  VARCHAR(50) NOT NULL)

Запись:

Код: Выделить всё

INSERT INTO SOME_TABLE (ID, NAME)
    VALUES (1, 'Здесь 17 символов')

Меняем длину поля NAME c 50 до 10 символов. При открытии таблицы сервер пишет о переполнении (что естественно), а при создании индекса по полю NAME:
"internal gds software consistency check (can't continue after bugcheck).".

Ибо нехрен лазить в системных таблицах грязными руками

А есть возможности менять домен поля DDL-ными средствами, не извращаясь с временным полем?

CyberMax писал(а):А есть возможности менять домен поля DDL-ными средствами, не извращаясь с временным полем?

Нет
А зачем ? Зачем вообще уменьшать р-р varchar поля ???

Я могу предположить ровно одну причину, но вряд ли её здесь назовут

hvlad писал(а):

CyberMax писал(а):А есть возможности менять домен поля DDL-ными средствами, не извращаясь с временным полем?

Нет
А зачем ? Зачем вообще уменьшать р-р varchar поля ???

Я могу предположить ровно одну причину, но вряд ли её здесь назовут

Уменьшить р-р индексов, р-р БД?

stix-s писал(а):

hvlad писал(а): А зачем ? Зачем вообще уменьшать р-р varchar поля ???

Я могу предположить ровно одну причину, но вряд ли её здесь назовут

Уменьшить р-р индексов, р-р БД?

Не угадал.

hvlad писал(а):

stix-s писал(а):

hvlad писал(а): А зачем ? Зачем вообще уменьшать р-р varchar поля ???

Я могу предположить ровно одну причину, но вряд ли её здесь назовут

Уменьшить р-р индексов, р-р БД?

Не угадал.

Глупость я сморозил, ни фига таким образом р-р не сэкономишь

hvlad писал(а):Зачем вообще уменьшать р-р varchar поля ???

Например, если обновленные бизнес-правила ограничивают длину varchar-поля меньшей длиной.

Да и дело-то не в смене длины varchar, а в концепции . Легальной команды смены домена не дали, но разрешили (или закрыли глаза на нее?) возможность менять его путем применения проктологических инструментов в виде IBE .

CyberMax писал(а):

hvlad писал(а):Зачем вообще уменьшать р-р varchar поля ???

Например, если обновленные бизнес-правила ограничивают длину varchar-поля меньшей длиной.

Вотпусть бизнес-правила и ограничивают. При чём тут физика хранения

CyberMax писал(а):Да и дело-то не в смене длины varchar, а в концепции . Легальной команды смены домена не дали, но разрешили (или закрыли глаза на нее?) возможность менять его путем применения проктологических инструментов в виде IBE .

RTFM: ALTER TABLE ALTER COLUMN

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

Вроде и сейчас это можно сделать:
Стартанули снапшот, проверили длинны, если блоьше - откатились, меньше alter table... + commit.
В чём проблемы?

CyberMax писал(а):могут ли в будущем сделать проверку при ALTER COLUMN varchar-поля в сторону уменьшения длины на невыход фактических длин строк поля за указанные пределы и принятия изменения в случае положительного результата?

разве что с эксклюзивной блокировкой всей таблицы с момента ALTER и до коммита

Внесете в трекер?

CyberMax писал(а):Кстати, Влад, есть какие-нибудь гарантированные побочные явления, когда длина varchar-поля меняется в меньшую сторону через вот такую правку систаблиц?

Сложно сказать. Надёжнее считать, что таки есть

CyberMax писал(а):И могут ли в будущем сделать проверку при ALTER COLUMN varchar-поля в сторону уменьшения длины на невыход фактических длин строк поля за указанные пределы и принятия изменения в случае положительного результата?

А оно надо ?
Я, лично, предпочитаю заниматься чем-то реально полезным

Особого удовольствия можно достичь, когда изменяемое хаком поле находится на одном из концов ФК

CyberMax писал(а):И могут ли в будущем сделать проверку при ALTER COLUMN varchar-поля в сторону уменьшения длины на невыход фактических длин строк поля за указанные пределы и принятия изменения в случае положительного результата?

Tonal писал(а):Стартанули снапшот, проверили длинны, если блоьше - откатились, меньше alter table... + commit.
В чём проблемы?

объясняю двадцатый раз:

1. в базе может быть туча записей не видимых конкретной транзакции
2. индекс всегда при создании "видит" все версии
3. штатного уменьшения размера строки в сервере нет.
4. про столбцы с зависимостями, индексами и т.п. я вообще умолчу.
5. если делать проверку, то делать для любых преобразований типов из типа А в тип Б, а не только на длину строки. Т.е. вместо вас, задумчивых девелоперов, это должен делать сервер? А если там будет 500 тысяч версий, скажем, удаленных другой транзакцией? Ах, они же "удаленные"? Ой, а почему мне сервер через два часа после alter выдал отлуп?

select CAST(FIELD as NEWFIELDTYPE) from TABLE

мойте руки ПЕРЕД едой. А не во время и не после.

kdv писал(а):4. про столбцы с зависимостями, индексами и т.п. я вообще умолчу.

Но ведь сервер не дает изменить тип поля, если на него есть ссылки?

kdv писал(а):2. индекс всегда при создании "видит" все версии

Если нет существующих записей с данными, выходящими за пределы размерности - то индекс создается без проблем.

kdv писал(а):5. если делать проверку, то делать для любых преобразований типов из типа А в тип Б, а не только на длину строки.

Не соглашусь. Например, преобразование из SmallInt в Integer, из Integer в BigInt, а также Varchar(10) в Varchar(50), то есть в сторону увеличения - в настоящее время разрешено, а вот обратно - запрещено, по причине того, что неизвестно - будет ли потеря данных из-за усечения, или нет.

Чем мешают удаленные записи?

Чем мешают удаленные записи?

версионность. ты хоть не прикидывайся.

короче, граждане, в сад. при изменении типа данных вы сами должны:

1. проверить конвертируемость на cast, для всех записей (fetchall)
2. убедиться что в данный момент нет застрявшей транзакции, которая чего-то модифицировала в противоречии с пунктом 1
3. если перед этим было массовое удаление или модификация записей, вы должны понимать что запрос п.1 может привести к сборке мусора (и лучше если приведет, чем оставит какие-нибудь древние версии с нарушением пункта 1)

то есть, фактически это делается в монопольном режиме.

kdv писал(а):1. проверить конвертируемость на cast, для всех записей (fetchall)
2. убедиться что в данный момент нет застрявшей транзакции, которая чего-то модифицировала в противоречии с пунктом 1
3. если перед этим было массовое удаление или модификация записей, вы должны понимать что запрос п.1 может привести к сборке мусора (и лучше если приведет, чем оставит какие-нибудь древние версии с нарушением пункта 1)
то есть, фактически это делается в монопольном режиме.

Фактически, с этим прекрасно может справиться и сервер. Выходит, вопрос только в том, надо ли это разработчикам и пользователям?

Фактически, с этим прекрасно может справиться и сервер.

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