On 1 Jun 2004 at 16:45, Ivan Prenosil wrote:

>> >In EmbeddedSQL or in FB API you can request invoking
>> >blob filter by specifying both FROM and TO sub_types.
>> >The CAST syntax allows to specify only one sub_type,
>> >that is why I do not like such solution.
>
>I did not described or experienced any crash regarding using blob
>filters. And you ?

I never used either UDFs or BLOB filters. Too paranoid to allow
server execute any external code. :-)

>What if I want to store any type of file in blob field, and be able to
>call different blob filters (e.g. to convert jpg->png, jpg->bmp,
>jpg->tif, wav->mp3, compress/decompress any file, encrypt/decrypt any
>file, etc.) With your proposal I would have to create special column
>for every possible blob sub-type. Absurd.

But how can you find out what filter you should call? An additional
field, I suppose. Have you seen how Borland implemented DB picture
handling? An additional header in BLOB data. So, one filter can
safetly recognize source format and either transform it into
requested format or raise error.

>In the past people already asked whether they can store blobs
>of different subtypes in single blob column.

I guess, that's what BLOB subtype 0 is used for: raw binary data.

>You are mixing types and subtypes.
>And if I want, I can store strings of different subtypes (i.e.
>charsets) into none-charset column.

And you can store different type of content into binary BLOB, but
here we are talking about different things. AFAIR, we are talking
about definite types of content and transforming this content by BLOB
filters. No?

>> I know that currently it is not true. Engine don't care about type
>> of BLOB at all.

As Ann mentioned, engine cares about pre-defined BLOB types. And
filters, IMHO, is the way to teach it how to care about other types.

>> >So what do you think will happen when you have blob column
>> >defined with sub_type -1, and when reading it you will request to
>> >use blob filter from -2 to -3 sub_type (which is allowed in ESQL or
>> >FBAPI) ?
>>
>> Big badaboom. And you still insist on specifying both FROM/TO
>> subtypes?
>
>No badaboom here. But even if there is some bug, why not just fix it
>instead of introducing some restrictions ?

Errr... Let's assume that -1 in your example is a zipped content,
-2 is a JPEG and -3 is BMP. What kind of picture you'll get as a
result? What kind of bug can be fixed here, except bug in design?

>> This is result of not enforcing subtype. Engine isn't sure what
>> data is stored in BLOB and don't take responsibility of converting
>> it.
>
>Is not blob usually defined as type that contains data server does not
>care about?

That's right. Everybody uses subtype 0 and server doesn't care. But
if server doesn't care, what are filters for? User application store
RAW data stream in BLOB field and user application should transform
it if necessary. Because only the application knows what has been
stored. Server doesn't.
Now, you, probably, are going to tell me that BLOB filters is a way
to provide the data in appropriate format to application that also
don't know how to transform it (report builders, for example). But,
unfortunatelly, these application also can't request filtering for
the same reason: they don't know what is stored on server because
server doesn't care.

[Jim wrote]

>The engine's responsibility is to store and fetch blobs, and if asked
>politely, find a filter to go from A to B. It was never intended that the
>feature would restrict usage.

I think this approach gives user too long rope.

[Ann wrote]

>Users are responsible for keeping their subtypes consistent
>because the engine doesn't, and shouldn't know the difference
>between a png and a jpg.

But the engine does and should know difference between "BLOB
sub_type n" and "BLOB sub_type m". And the engine must use
appropriate filter for casting between them basing on DBA
information, kept in metadata, not current-user whim.

>----
>Also, IIRC, Jim said that original architecture allowed blob filters
>to reside anywhere between client and server (i.e. not necessarily on
>server machine). It is apperently not possible anymore, but if this
>functionality was restored, creating auxiliary blobs could cause
>unnecessary ping-pong of blob data between machines.

Why? Filter accepts stream as input and give out a stream. If
filtering takes place on server side, output goes into temporary
BLOB. On client side it goes directly to app buffer through
get_segment().

SY, Dimitry Sibiryakov.