At 09:11 AM 12/2/2004, Olivier Mascia wrote:

>What physical differences does it make to the database internals wether
>a stream blob or a segmented blob is used. Is the internal storage
>really different ?

As in my earlier post, yes. Segmented blobs include segment
length words. Streams blobs are just data - plus page and
record overhead, as pertains.

>Though I have not yet spent the required time to verify this in the
>source code, it looks to me that those STREAM* / Bopen / putb / putbx /
>getb / isc_seek_blob / BLOB_close are just a hack

"Frosting" is a nicer word. That's true of Bopen, putb, putbx,
and getb, but they're a hack on top of the stream blob calls,
not the segmented blob calls. The "real" calls are BLOB_open,
BLOB_get, BLOB_put, BLOB_close.

The getb/putb things are macros like getc and putc, that fill
and dump buffers so you're not actually making a round trip to
the database for each byte.

BLOB_open takes the handle of an open blob and creates a BSTREAM
block - a control block that manages the positioning in a stream
blob. Bopen combines that with the actual opening of the blob.
I thought it was easier to have one call. I didn't do a Bclose
because it would have exactly the same arguments and effect as
BLOB_close.

>over the basic real
>blob handling which is inherently 'segment' based, at least due to page
>storage.

No. Both types of blobs have the same basic storage mechanism - a
blob-id that decomposes into a record number that locates a data
page and an offset in the page/line index. The page line index
entry points to an entity with a variant of a record header called
a blob header. The data portion is either the whole blob - if
it's small, a vector of page numbers of blob pages - if it's
medium sized, or a vector of page numbers of pages of vectors of
page numbers if it's large.

The blob data, however, is different in the two cases. Segmented
blobs have segment lengths sprinkled through the data. Stream
blobs don't.

>Also this API seems completely built despite of any good sense
>(I don't want to be rude on anybody by writing this, but it clearly
>looks like mess than good order).

Guilty.

>Not even the naming of the functions
>is coherent. We have Bopen but BLOB_close, we have putb/putx/getb but
>isc_seek_blob... What happened to that area of the API during the
>Borland days or before ?

It was before, and it was me. There's an underlying set of calls -
BLOB_open, BLOB_get, BLOB_put, and BLOB_close.

>Am I wrong when I think that isc_seek_blob can actually be used with so
>called segmented blobs ? That one does not take a STREAM* but a plain
>isc_blob_handle as expected...

However, it will get the wrong answer if used on a segmented blob
because of the segment boundaries.

>Is it true that a blob written using the above set of calls can later be
>retrieved using the common set of APIs (isc_create_blob2 /
>isc_open_blob2 / isc_close_blob / isc_cancel_blob / isc_blob_info

Those work.

>isc_get_segment / isc_put_segment /

those don't.

Regards,


Ann