BLOB Фильтр

ivl · Сообщение **ivl** » 04 май 2006, 20:07

Написал BLOB фильтр.
Положил dll'ку в UDF
Выполнил DECLARE FILTER ...

Но он не работает. (Не вызывается)
Может подскажете, что я упустил в этой цепочке и где взять подробную информацию по BLOB фильтрам.
Заране спасибо

Сообщение **kdv** » 04 май 2006, 20:37

Но он не работает. (Не вызывается)

как вызываешь?

ivl · Сообщение **ivl** » 04 май 2006, 21:31

kdv писал(а):
Но он не работает. (Не вызывается)
как вызываешь?

Вообщем-то явно никак: я, по глупости, думал, что при совпадении исходного и результирующего подтипов он должен вызваться автоматически.
Единственый способ, который мне известен, явно вызвать - это применение курсора
(что-то типа этого DECLARE ВС CURSOR FOR
INSERT BLOB BLOB1 INTO TABLE1
FILTER FROM -1 TO -2; )
но как его применить, учитывая, что я использую IBX я не знаю.

Dimitry Sibiryakov

В IBX - никак. Фильтр указывается в bpb на уровне API. IBX эту возможность не реализует, ЕМНИП.

Сообщение **kdv** » 05 май 2006, 09:45

собственно, фильтр это конвертер между разными blob_subtype.

ivl · Сообщение **ivl** » 05 май 2006, 10:11

kdv писал(а):собственно, фильтр это конвертер между разными blob_subtype.

Это я прекрасно понимаю. Для того и писал. Хотел хранить в одном формате, а при чтении, прозрачо для
клиента получать в другом.

Dimitry Sibiryakov писал(а):В IBX - никак. Фильтр указывается в bpb на уровне API. IBX эту возможность не реализует, ЕМНИП.

Тогда возникает вопрос: возможно ли применение фильтра в хранимой процедуре (Вызов внутри хранимой процедуры)?

Dimitry Sibiryakov

Насколько я знаю - тоже нет.

ivl · Сообщение **ivl** » 05 май 2006, 14:38

Dimitry Sibiryakov писал(а):Насколько я знаю - тоже нет.

Это, конечно, не вселяет оптимизма, но может имеется у кого-нибудь информация о том планируется ли такая возможность
(вызова в хранимых процедурах или неявного вызова по совпадению
подтипов BLOB) в будущих версиях Interbase или Firebird (Например Firebird 2.0 или более поздних)?

Сообщение **kdv** » 05 май 2006, 15:49

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

ivl · Сообщение **ivl** » 05 май 2006, 16:39

kdv писал(а):в Firebird 2.0 нет, в более поздних - не совсем понятно, какую "возможность" ты имеешь в виду. пример приведи - запрос и как бы оно должно работать.

Предположить можно, конечно.
Например:
1. При создании таблицы указать для каких полей какие фильтры должны срабатывать автоматически, без какого-либо дополнительного вызова.
2. Или, как вариант, в операторе SQL что-то типа такого
SELECT blob_field1 FILTRED BY <имя фильтра>,
field2, field3
FROM teble1
3. Или, если с использованием курсора, то создать курсор и хранить его в базе данных (не в процедуре или триггере).
4. Ну на крайний случай, с тем же курсором в хранимой процедуре, но без какого-либо дополнительного вызова API. Только с использованием SQL.

Сообщение **kdv** » 05 май 2006, 17:39

все это очень мутно, т.к. фильтры, повторюсь, предназначены для автоматической конвертации из одного типа блоба в другой. Фильтр, один, конвертирует только в одну сторону. Откуда и куда.

потом, вызов фильтра осуществляется хитрой конструкцией embedded sql - DECLARE CURSOR FOR READ BLOB/INSERT BLOB/FILTER FROM TO.

то есть, в SQL это недоступно. Я бы сделал на твоем месте вот что - написал бы на embedded sql вот такой кусок, и посмотрел бы, в какие вызовы API это конвертируется. Понятно, что никакие компоненты в данный момент это не поддерживают.

я бы лучше предложил разработчикам FB, чтобы фильтры звались при CAST(FIELD AS BLOB SUBTYPE X), автоматом из типа блоба FIELD в тип SUBTYPE X. возможно, это наименее проблемный вариант, чем введение каких то специальных конструкций SQL на тему совершенно нестандартных фильтров....

ivl · Сообщение **ivl** » 05 май 2006, 20:17

kdv писал(а):все это очень мутно, т.к. фильтры, повторюсь, предназначены для автоматической конвертации из одного типа блоба в другой. Фильтр, один, конвертирует только в одну сторону. Откуда и куда.

Это не совсем так. Один фильтр может и туда и обратно (в него передаются исходный и результирующие подтипы)

kdv писал(а): то есть, в SQL это недоступно. Я бы сделал на твоем месте вот что - написал бы на embedded sql вот такой кусок, и посмотрел бы, в какие вызовы API это конвертируется. Понятно, что никакие компоненты в данный момент это не поддерживают.

Жаль, что так. Я уже подумываю передетать фильтр в UDF'ки. И использовать в представлении вместе с триггерами замещения на вставку и редактирование. Но тут вся прозрачность потеряется.

kdv писал(а): я бы лучше предложил разработчикам FB, чтобы фильтры звались при CAST(FIELD AS BLOB SUBTYPE X), автоматом из типа блоба FIELD в тип SUBTYPE X.

Да, наверное, это более корректно. Я бы тоже предложил, знал бы как и кому

Сообщение **kdv** » 05 май 2006, 23:21

И использовать в представлении вместе с триггерами замещения на вставку и редактирование.

ты, часом, не паковать-распаковывать блобы собрался? Забей.

ivl · Сообщение **ivl** » 06 май 2006, 00:16

kdv писал(а):
И использовать в представлении вместе с триггерами замещения на вставку и редактирование.
ты, часом, не паковать-распаковывать блобы собрался? Забей.

Так и есть. База содержит большой объём "рыхлых" данны в BLOB полях.
Таблицы с такими данными использоваться должны не очень часто (даже редко), а занимают места много. Так почему же их не паковать?
Почему "забить"? Есть какие-то рациональные предпосылки отказаться от приблизительно 30%-й экономии места? Паковать в клиенте я не могу.
Здесь бы очень помог бы BLOB фильтр, но не судьба наверно. Может какой другой способ компрессии есть?

Сообщение **kdv** » 06 май 2006, 10:21

обычно или пакуют сразу, а распаковывают только на клиенте, для этого в FIBPLus целая система есть. или, если их еще и на сервере надо обрабатывать, хранят как файлы, вне БД.

ivl · Сообщение **ivl** » 06 май 2006, 14:16

О FIBPLus я, конечно, знаю. Но мало того, что это отдельная библиотека, так это ещё и нарушает единообразный доступ к данным (из различных приложений) завязывая всё на конкретный клиент.
Что касается отдельного хранения файлов, то я не совсем понял, что конкретно имеется в виду?
1. Хранение файлов отдельно с доступом к ним минуя СУБД?
(плохой вариант, по-моему)
2. Хранение файлов отдельно с доступом к ним через СУБД, например через UDF или те же фильтры? (вариант, по-моему, тоже не особо лучше).
3. Хранение данных во внешних таблицах?

Может я упустил ещё какой-то вариант?

В моем же случае пункты 1 и 2 привли бы к появлению тысяч относительно мелких файлов.
Ниужели никто не хранит упакованные на сервере данные в BLOB полях?

Сообщение **kdv** » 07 май 2006, 09:50

Ниужели никто не хранит упакованные на сервере данные в BLOB полях?

"нЕужели". хранят, конечно. или незапакованные, или запакованные.

ivl · Сообщение **ivl** » 07 май 2006, 13:45

Спасибо, конечно, что обратили внимание на мою ошибку, но мне бы всё-таки хотелсь узнать какие механизмы испольуются при храненни файлов отдельно от самой базы.
Почему я считаю хранение отдельных от базы файлов с доступом к ним, например, через UDF неудачным? На мой взгляд это нарушает механизм транзакций.
Если я упускаю какой-то другой вариант с отдельными файлами, то приведите пример как это можно сделать. Заранее благодарю.

Сообщение **kdv** » 07 май 2006, 16:24

это нарушает механизм транзакций.

нарушает. но иногда это бывает не надо. особенно если файлы не модифицируются. или их очень много, и к ним надо в том числе обеспечивать внешний доступ.
В общем, совсем не улыбается перечислять тебе все то, что обсуждалось по этой теме как на этом форуме, так и на sql.ru. Твой вопрос возникает раз в полгода минимум, так что тему обмусолили уже до невозможности.

Если ты хочешь совета, то опиши, что ты хочешь сделать. Не хочешь совета - копай сам. Заранее предупрежу что в этом топике мое письмо последнее - есть другие дела...