Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Firebird, InterBase Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7   вперед  Ctrl      все
 Re: Корректное завершение gbak/isql при b/r  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10079
Arioch,

причём тут DataSet. Никто не агитирует от него отказываться, кроме DS.

Arioch
Смотрите, я написал на FireDAC/DBX/IBO и не лез в FB-OO-API - не выпендрёж


ты это не в тему сказал. Речь о том кто будет в эти библиотеки добавлять поддержку новых фич из 4-ки.

Вот у МП, например, свой клон IBX, если ему надо будет добавить новые плюхи, то придётся разбираться с API.
Если нет аналога в старом, то придётся в новое лезть, только и всего.

Перечислю основное, что придётся добавить:
- поддержка тайм-аутов
- поддержка timezone
- поддержка NUMERIC и DECIMAL c точностью 38 (INT_128)
- поддержка DECFLOAT(16), DECFLOAT(34)
- поддержка batch-api

Если тебе этого не надо. или кто-то из компоненто-писателей уже сделал это, то и обсуждать не чего. Заметь я не агитирую за использование API вместо чего-то там вообще.
4 окт 19, 19:28    [21987094]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10079
Dimitry Sibiryakov
Симонов Денис
конечно кусок. Но не портировать, а использовать.

На пути "использовать" лежат забавные грабли с загрузкой библиотеки и импортом, но да,
наверное есть ещё любители геморроя себе на шею.


вот здесь не понял. Ты в LegacyAPI импортируешь десятки функций, с чего бы импорт ещё одной должен дать какие-то грабли?
4 окт 19, 19:40    [21987100]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Arioch
Member

Откуда:
Сообщений: 11041
Симонов Денис
Если нет аналога в старом, то придётся в новое лезть, только и всего.


но речь шла про int128 - а его вроде бы уже протащили в старый API, во всяком случае константы sql_type цитировали
4 окт 19, 19:42    [21987101]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10079
Arioch,

эти константы не только для старого API. И да в SQLVAR поместить то можно любой тип. Речь о том что ты будешь делать с этим указателем. Как в Delphi он должен обрабатываться?
Варианта 2: воспользоваться хелперами из нового API, или раскатывать структуру руками.

вот тебе

struct FB_I128_t {
	ISC_UINT64 fb_data[2];
};

typedef struct FB_I128_t FB_I128;


расскажи нам как ты это в BCD раскатаешь?
4 окт 19, 19:57    [21987105]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Arioch
Member

Откуда:
Сообщений: 11041
Симонов Денис,

посмотрю, как во времена Delphi 5 или Delphi 2006 переводили int64 в TField.AsDouble и сделаю аналогично

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

Только копировать надо будет не из SQLDA, а из твоего хелпера.
4 окт 19, 20:16    [21987112]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10079
Arioch,

там есть поле типа FMTBcd в него можно закатать.

Вариант 1. Берём указатель из SQLDA и вызываем в хелепере функцию toBcd, если она бинарно совместимо, то следом

function BcdFromBytes(const AValue: TArray<Byte>): TBcd;

Если нет, то вариант 2. Вызываем из хелпера toString. Далее

function StrToBcd(const AValue: string): TBcd; overload;
4 окт 19, 20:44    [21987125]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 48611

Симонов Денис
Ты в LegacyAPI импортируешь десятки функций, с чего бы импорт ещё одной должен дать
какие-то грабли?

Так и речь-то не обо мне, а о тех между кем и уже импортированными функциями две
жирных-жирных библиотеки. Вот топик для размышления:
https://www.sql.ru/forum/1316505/firedac-i-firebird-shifrovanie
Арефьев, там, кстати, так и не показался.

Posted via ActualForum NNTP Server 1.5

4 окт 19, 21:29    [21987148]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Vlad F
Member

Откуда:
Сообщений: 986
Dimitry Sibiryakov,

А какая вторая из "две"? И, кстати, ваш покорный слуга как раз из той организации, где вполне бы был востребован decfloat и как раз через фаердак, на которые , в симбиозе, весь прошлый год я лелеял надежды. Но теперь уже совершенно ясно, что внедрить FB4 в одной из самых известных структуре в стране уже не успею, время вышло. А жаль.
4 окт 19, 21:57    [21987154]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 48611

Vlad F
А какая вторая из "две"?

VCL+половина FireDAC-а и вторая половина FireDAC-а, так называемый "физический слой".

Posted via ActualForum NNTP Server 1.5

4 окт 19, 22:10    [21987158]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Vlad F
Member

Откуда:
Сообщений: 986
Dimitry Sibiryakov,

Я понял. Но боюсь, что все это теперь придется оставить уже на нового работодателя и на новое десятилетие.))
4 окт 19, 22:15    [21987161]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 30556

04.10.2019 22:10, Dimitry Sibiryakov пишет:
> вторая половина FireDAC-а, так называемый "физический слой".

вот за это я его и не люблю.
даже кушать не могу! (С)

Posted via ActualForum NNTP Server 1.5

7 окт 19, 11:44    [21988035]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10079
Мимопроходящий,

ну им надо было чем-то заменить BDE. ADO у них сделан так себе. Собственная разработка dbExpress тоже. По сравнению с ними универсальный FireDac очень даже ничего. Кому не нравится могут продолжать пользоваться IBX/FibPlus и так далее. Хот прямым API
7 окт 19, 11:53    [21988044]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 30556

07.10.2019 11:53, Симонов Денис пишет:
> ну им надо было чем-то заменить BDE.

они об этом не думали вааще.
Арефий сам по себе такое решил.
а Дебаркадеры купили готовое решение.

Posted via ActualForum NNTP Server 1.5

7 окт 19, 11:58    [21988052]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10079
Мимопроходящий,

погоди. У Арефьева была цель сделать универсальный компонент доступа к БД. Он это сделал, по-моему мнению весьма не плохо, в особенности по сравнению с тем что предлагали в Embercadero.
Дебаркадера поняла что ихние универсальные компоненты доступа мягко говоря гомно, стали искать чем бы заменить и их выбор пал на AnyDac (на их месте вполне мог оказаться UniDac).

Понятное дело что специализированный компонент под конкретную СУБД всегда можно сделать более гибким. Но у FireDac такой цели нет. Посмотри с другой стороны, кто сейчас делает и поддерживает хоть один из специализированных компонентов доступа?

IBX сосредоточена на IB им плюшки FB до лампочки, разве что самому точить, как ты это делаешь.

FibPlus никто не поддерживает, есть некий клон, но насколько он актуален неизвестно. Да и вообще возникают проблемы с чистотой этого клона. Опять же систематически его никто не правит, какой-то обратной связи в плане поддержки нет. Что остаётся?

Как бы не был сделан FireDac у него хотя бы есть обратная связь, плюшки новых версий FB в него портируются, ошибки правятся.
7 окт 19, 12:14    [21988067]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 48611

Симонов Денис
Дебаркадера поняла что ихние универсальные компоненты доступа мягко говоря гомно, стали
искать чем бы заменить и их выбор пал на AnyDac (на их месте вполне мог оказаться UniDac).

Универсальных компонент доступа у них никогда и не было. Была BDE, купленная с Аштонами,
dbExpress, купленный позже и оказавшийся хуже BDE, а теперь вот FireDAC, который, конечно,
лучше Экспресса, но до уровня BDE пока так и не дотянувшийся.

Posted via ActualForum NNTP Server 1.5

7 окт 19, 12:28    [21988089]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Arioch
Member

Откуда:
Сообщений: 11041
Симонов Денис
там есть поле типа FMTBcd в него можно закатать.


агась, в него родного и закатывали. До сих пор хвосты попадаются в старой прикладухе, которая начиналась с BDE/Paradox через BDE/IB5/Dialect1 и в dbx/Firebird/Dialect3

Вариант 1. Берём указатель из SQLDA и вызываем в хелепере функцию toBcd, если она бинарно совместимо, то следом function BcdFromBytes(const AValue: TArray<Byte>): TBcd;


Ё! ещё и указатель надо взять не НА DA, а ИЗ DA. Т.е. DA придётся руками парсить. К вопросу о полезности хелперов, которые по идее должны превращать низкоуровневый опасный код в высокоуровневый безопасный.

Кстати, спасибо за наводку. Глянул я внутрь этой функции.... buffer overrun на чтение. Размер входного буфера никто не проверяет. И вообще всё, что она делает по сути - это один вызов Move (memory copy), только расписанный на три раздельных операции, чтобы подольше исполнялось. Характерно, что в списке typecast'ов у TBcd этого мрака нет. Видимо осталось с каких-то совсем древних времён чисто ради совместимости. Возможно, ради совместимости с .Net.

В общем, если там и делать Delphi helper, то возвращать он должен не TBytes (неформатированный дамп который может совпасть по длине и внутреннему содержимому с TBcd, а может и не совпасть), а сразу готовый TBcd. И не по указателю "из" SQLDA, а "на" SQLDA. Иначе смысла в таком хелпере не много остаётся.

А сейчас получится, что для доработки TDataSet у нас будет
1. самостоятельная привязка к буферам, TFieldDefs и прочей внутренней кухни TDataSet
2. самостоятельный парсинг низкоуровневой структуры XSQLDA (с проверкой на dialect 0 SQLDA)
3. дёрганье хелпера, создающего "сырой" дамп в TBytes - ARC-структуре, т.е. запускающего две глобальные блокировки потоков процессора, как минимум две.

"В таком аксепте" я бы этим хелпером пользоваться не стал, а либо выдрал из него код копипастом (это хоть какое-то, но использование), а вероятнее таки написал бы сам на основе ib6 api guide. Потому что на фоне 1 и 2 экономия усилий от его использования небольшая, при этом возникает ИЛЛЮЗИЯ высокоуровневого безопасного кода плюс ненужные блокировки.
7 окт 19, 12:31    [21988093]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 30556

07.10.2019 12:14, Симонов Денис пишет:
> Как бы не был сделан FireDac...

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


Posted via ActualForum NNTP Server 1.5

7 окт 19, 12:32    [21988095]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10079
Dimitry Sibiryakov,

чего это не дотянувшийся до BDE? Что в BDE есть такого чего нет в FireDac?
Если что-то глюкнуло в BDE, то внутрь уже никак не пролезешь хоть лопни.
7 окт 19, 12:34    [21988097]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Arioch
Member

Откуда:
Сообщений: 11041
Мимопроходящий
04.10.2019 22:10, Dimitry Sibiryakov пишет:
> вторая половина FireDAC-а, так называемый "физический слой".

вот за это я его и не люблю.
даже кушать не могу! (С)


Ну так - оно всё такое. И вообще, как делать унифицированный интерфейс без abstraction layer, как ты его не назови?

DBX - в качестве "физического слоя" используется "провайдер" с закрытыми исходниками и минимумом документации, написанный вокруг COM-модели, с вероятной целью унифицировать нативный и .NET-ный Delphi

Что интересно, китайцы написали альтернативный Firebird DBX Provider - но исходников так же не выложили.

BDE - в качестве "физического слоя" выступает сам BDE. С закрытыми исходниками, изначально рассчитанный на ISAM с SQL прикрученным "сбоку бантик" задним числом, давно не поддерживаемый, по факту почти не совместимый с современными Windows, и гораздо более сложный (кто-нибудь видел сторонний drop-in replacement для BDE?)

Я таки тоже не вижу смысла в претенизии к AnyDAC с этой стороны. Разве что как завуалированную претензию к универсальности AnyDAC. Ну так если кому-то нужно "close to metal" - то есть и UIB и IBX
7 окт 19, 12:42    [21988103]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 48611

Симонов Денис
Что в BDE есть такого чего нет в FireDac?

Кэширование резалт-сета на диске. Он не сожрёт всю память на большом запросе.

Posted via ActualForum NNTP Server 1.5

7 окт 19, 12:42    [21988105]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10079
Мимопроходящий,

речь не об универсальном решателе задач. Речь о том, что в сообществе FB никто не делает заточенного под него компонента на Delphi и уже давно, кроме разве что энтузиастов. Если приходит нуб, у которого нет собственных наработок за последние 10 лет, то ему проще взять FireDac, нежели IBX начинать в него портировать плюшки FB за последние 15 лет. Сейчас начинать разработку на Firebird стало сложнее увы
7 окт 19, 12:42    [21988106]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Arioch
Member

Откуда:
Сообщений: 11041
Симонов Денис
Что в BDE есть такого чего нет в FireDac?


прямая работа с файлами Paradox
7 окт 19, 12:43    [21988108]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 30556

07.10.2019 12:42, Симонов Денис пишет:
> Если приходит нуб, у которого нет собственных наработок за последние 10
> лет, то ему проще взять FireDac,

это если ньюб приходит сразу же на распоследние версии Delphi.
а если на Лазаря, то там есть выбор.

а вообще, Delphi(как продаваемый продукт) must die!

Posted via ActualForum NNTP Server 1.5

7 окт 19, 12:49    [21988115]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Arioch
Member

Откуда:
Сообщений: 11041
"Плюшки за 15 лет" для "нуба", которому надо "начинать разработку на Firebird" - они сильно overrated

логиновские FB IBX Utils никто не отменял, если "нуб" по инерции с IBX начнёт.

UIB в режиме Firebird 2.5 даст всё, что нубу будет нужно в ближайшие пару лет.
Включая такую приятную мелочь, как вычитывание запросов в виде
type Q1 = record ..... end;
var R: Q1;
begin
   Query1.open;
   for R in Query1.All<Q1> do begin ... end;


К сожалению, из за убогого полуживого type inference в Delphi тип переменной надо явно объявлять, иначе бы ещё красивее было.

И какой такой killer feature при этом лишится "начинающий разработку" "нуб" ?
7 окт 19, 12:50    [21988117]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10079
Arioch
Ё! ещё и указатель надо взять не НА DA, а ИЗ DA. Т.е. DA придётся руками парсить.


не надо там ничего парсить. Сразу видно не разбирался.

Arioch
Размер входного буфера никто не проверяет


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

Arioch
с проверкой на dialect 0 SQLDA


этого не нужно. Старый диалект только для совместимости со старыми компонентами. Он не используется уже лет 15. Разве что в недрах старого BDE. В новом API этого понятия нет вообще.

Arioch
3. дёрганье хелпера, создающего "сырой" дамп в TBytes - ARC-структуре, т.е. запускающего две глобальные блокировки потоков процессора, как минимум две.


сразу видно что ты не пытался разобраться. Нет там никаких блокировок. Хелпер надо получить ровно один раз, а потом пользоваться им. В нём нет глобального состояния.
7 окт 19, 12:52    [21988120]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7   вперед  Ctrl      все
Все форумы / Firebird, InterBase Ответить