"Tonal" ...
>
> Vlad Horsun пишет:
> > "Tonal" ...
> >> Идея простая: сделать клиентскую конвертацию типов на основе доменов.
> >> D_BOOL <-> bool, D_ICON <-> TIcon, D_XML <-> TXmlDocument...
> >> В случае, если домена нет, например для выражения, можно использовать
> >> базовый тип или явно кастить. Но сейчас явно кастить бессмысленно, т.к.
> >> всё равно на клиенте информации о домене не получишь.
> > Если различия в типах (доменах) понятно только клиенту, то не нужно
> > тянуть это в сервер. Серверу фиолетово что хранить в блобе - TIcon или
> > TXmlDocument.
> TIcon можно и в varchar-е хранить, да и xml тоже.
И это тоже серверу фиолетово
> Причём конкатинировать D_XML может быть вполне осмысленно, а D_ICON
> точно нет. ;-)
И это тоже серверу фиолетово
> Если сервер различает домены в параметрах процедур и при явном касте,
> почему не дать получить эту инфу клиенту, чтобы он мог её тоже использовать.
Клиент, если ему сильно приспичит, может и сейчас иметь всю эту инфу
> Сейчас, я вижу только 2 возможности конвертации типов:
Я не понимаю что это и зачем
> 1) Кодировать для каждого запроса позиционно или по именам
> 2) Использовать соглашения о наименовании однотипных полей.
> Первое - утомительно, а значит провоцирует ошибки.
> Второе - излишне при присутствии системе доменов.
3. прочитать то, что писали тебе в этой ветке
> Если дать возможность быстро получить домен, будет ещё третий путь.
Это излишне и никому не нужно. Кому нужно - прочитает RDB$FIELDS,
RDB$RELATIONS и RDB$RELATION_FIELDS один раз и воспользуется XSQLVAR
для поиска
> Ну и кроме того, основываясь на этих сведениях некоторые ошибки можно
> будет отловить на этапе prepare:
> update T1 set IS_ACTIVE = ? where ID = ?
> Клиент после prepare увидит что IS_ACTIVE имеет домен D_BOOL стало быть
> в его нельзя совать 10. ;-)
Это сугубо личные проблемы писателя этого клиента.
--
Хорсун Влад
PS Советую таки отделять сферы ответственности и научиться извлекать выгоду
из сокрытия представления иф-ции разными уровнями ПО
