Использование доменов в ХП

[DSKalugin]

FireBird 1.5.1
Сделал домен

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

CREATE DOMAIN TPRICE AS DOUBLE PRECISION

Прописал его в табличках вместо типов цен.
Но почему-то хранимые процедуры не хотят воспринимать параметры типа TPRICE.

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

CREATE PROCEDURE get_price (id_vs integer)
RETURNS (
    SELLER_COD VARCHAR(35),
    ZAK_PRICE tprice,
    SELL_PRICE tprice)
AS
...

Если написать тип цен DOUBLE PRECISION - все ок.
Почему так? Недоработка разработчиков или впринципе так и задумано?[/code]

[kdv]

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

[DSKalugin]

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

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

[kdv]

с таблицами проще. потому что процедуры и триггеры, в отличие от всего остального (кроме view), при создании компилируются в код (BLR) и затем исполняется только этот код, а не текст SQL. Соответственно, при любых внешних модификациях код может просто перестать работать.
Для этого вводятся т.н. dependencies, которые например не дают удалить PK если на него ссылается FK, не дают удалить таблицу, используемую в процедуре, и т.п. Сюда же относится и изменение типов столбцов или доменов.

[DSKalugin]

Сюда же относится и изменение типов столбцов или доменов.

C ХП и трипперами понял, ну а как для таблиц всетаки
домен меняется свободно не взирая на зависимости
или придется делать чтото типа ?

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

alter table BOOK_MAKERS add tmp tfirma;
update BOOK_MAKERS set tmp=MAKER_NAME;
alter table BOOK_MAKERS drop MAKER_NAME;
alter table BOOK_MAKERS add MAKER_NAME tfirma NOT NULL;
update BOOK_MAKERS set MAKER_NAME=tmp;
alter table BOOK_MAKERS drop tmp;

[kdv]

есть шанс получить в голову канделябром см. документацию на тему alter domain. причем alter domain работает И для "доменов" rdb$nnn в rdb$fields, то есть для обычных столбцов, но не по имени столбца в таблице, а по имени его "домена" в rdb$fields.

с другой стороны - стоит ли делать все эти выкрутасы с заменой столбца на домен? ну ладно, not null. Но вообще то флаг null/ not null и так есть у столбца, и без домена. и по идее его можно переключать без мучений с доменом.

ну и потом, это дело вкуса и клиентских приложений. можно не писать у столбца not null, и сделать так что null туда никогда не попадет.

[Merlin]

C ХП и трипперами понял, ну а как для таблиц всетаки
домен меняется свободно не взирая на зависимости

Дело в том, что альтер что домена, что непосредственно типа поля (что на самом деле за кадром транслируется в альтер его индивидуального системного домена) происходит без каких-либо изменений в данных. Каждая запись таблицы содержит информацию о формате, в котором пребывала таблица в момент её записи (хранится в таблице RDB$FORMATS). При любом обращении к записи сервер, располагая информацией о формате записи и текущем формате таблицы, приводит её к текущему, вот и всё. Тем не менее, после альтера типа колонки рекомендуется сделать update table set thiscolumn=thiscolumn, некоторые преобразования типов получаются не совсем корректно (какие именно - не помню). Что тоже говорит не в пользу использования общих доменов - в этом случае надо бы отследить все таблицы и проапдейтить. Ещё одни грабли - запросто можно на уровне описания поля, базирующегося на пользовательском домене, изменить свойства, например добавить check. Никто не гарантирует, что описания не вступят в конфликт.

[kdv]

что как оказалось, написано в www.ibase.ru/devinfo/metaver.htm ...
чего только не найдешь у меня в "загашниках"...

[Merlin]

что как оказалось, написано в www.ibase.ru/devinfo/metaver.htm ...
чего только не найдешь у меня в "загашниках"...

Это укор или и сам забыл?

[kdv]

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