Add blob information item to query if something is an inline blob?

[Mark Rotteveel]

As far as I'm aware, you can't know - for fbclient at least - if the
blob you have open is an inline blob or a server-side blob. Should a
blob info item be added to report this?

Say, an `isc_info_blob_inline` where the server always respond with `0`,
and the client, if the handle uses an inline blob, responds with `1`. It
could even be sent in `p_blob_info` of `op_inline_blob`, but then the
server obviously will need to send `1`, and not `0`.

To be honest, the only use case I can think of is debugging and testing
purposes of a driver implementation that wants to check if they are
using inline vs server-side blobs as they expect, but I think that
should be a good enough reason to add this.

Mark
--
Mark Rotteveel

[Dimitry Sibiryakov]

'Mark Rotteveel' via firebird-devel wrote 19.05.2025 13:28:
> To be honest, the only use case I can think of is debugging and testing purposes
> of a driver implementation that wants to check if they are using inline vs
> server-side blobs as they expect, but I think that should be a good enough
> reason to add this.

IIRC, such driver can disable inline BLOBs in DPB to be sure that all BLOBs
are received from server.

--
WBR, SD.

[Mark Rotteveel]

That is not my point. I want to be able to detect whether I'm using an
inline blob or not, so that I can *test* and *confirm* that I'm doing
the right things.

Additionally, I can foresee issues that might arise from implementation
differences between inline blob and server-side blob, and in that case
it can be good to be able to *know* what you have open to narrow down
the problem. Sure, this last thing could also be done by setting the
cache size or inline blob size to 0, but the previous thing you can't.
Additionally, maybe I simply want to log it, so if issues arise, I can
always find out after the fact.

Mark
--
Mark Rotteveel

[Vlad Khorsun]

19.05.2025 14:28, 'Mark Rotteveel' via firebird-devel:

I'm not sure we should add such info item... But, if do - it will be client-only
item and should never reach server. Only client knows if data of given blob instance
was received inline and not throwed out (cache full or by another reason).

If you really need it, please create a ticket and I'll implement it.

Regards,
Vlad

PS you may know if blob data was sent inline or not - by comparing wire stats
before and after open/get_segment.

[Mark Rotteveel]

On 19/05/2025 19:01, Vlad Khorsun wrote:
>   I'm not sure we should add such info item... But, if do - it will be
> client-only
> item and should never reach server. Only client knows if data of given
> blob instance
> was received inline and not throwed out (cache full or by another reason).

Having the server be aware of the item, and respond with the "no this is
not an inline blob" response item makes for a more uniform API (e.g. if
a driver does not use fbclient, doesn't have inline blob support or
something, but one of their users is aware of this info item).

>   If you really need it, please create a ticket and I'll implement it.

I'll think about it a little more. It might be a bit too esoteric for
only my testing purposes.

> PS you may know if blob data was sent inline or not - by comparing wire
> stats
> before and after open/get_segment.

That might be an alternative for my purposes. Are those exposed in the
legacy API? If so, how?

Mark
--
Mark Rotteveel

[Vlad Khorsun]

19.05.2025 20:10, 'Mark Rotteveel' via firebird-devel:

> On 19/05/2025 19:01, Vlad Khorsun wrote:
>>    I'm not sure we should add such info item... But, if do - it will be client-only
>> item and should never reach server. Only client knows if data of given blob instance
>> was received inline and not throwed out (cache full or by another reason).
>
> Having the server be aware of the item, and respond with the "no this is not an inline blob" response item makes for a more uniform
> API (e.g. if a driver does not use fbclient, doesn't have inline blob support or something, but one of their users is aware of this
> info item).

Server have no idea about client state. Server could keep blob_id's that was sent
inline, but there is no guarantee that inline data was really used by client. I see
no reason to make server to waste time and memory for this.

Also, driver that not uses fbclient should know if it received op_inline_blob for
given blob_id, or not.

>>    If you really need it, please create a ticket and I'll implement it.
>
> I'll think about it a little more. It might be a bit too esoteric for only my testing purposes.
>
>> PS you may know if blob data was sent inline or not - by comparing wire stats
>> before and after open/get_segment.
>
> That might be an alternative for my purposes. Are those exposed in the legacy API? If so, how?

Yes, it is implemented with new set of items (counters) for IAttachment::getInfo() (isc_database_info())
See details at https://github.com/FirebirdSQL/firebird/pull/8310

Regards,
Vlad

[Mark Rotteveel]

On 19/05/2025 19:28, Vlad Khorsun wrote:
> 19.05.2025 20:10, 'Mark Rotteveel' via firebird-devel:

>> Having the server be aware of the item, and respond with the "no this
>> is not an inline blob" response item makes for a more uniform API
>> (e.g. if a driver does not use fbclient, doesn't have inline blob
>> support or something, but one of their users is aware of this info item).
>
>   Server have no idea about client state. Server could keep blob_id's
> that was sent
> inline, but there is no guarantee that inline data was really used by
> client. I see
> no reason to make server to waste time and memory for this.

I'm not asking for the server to track anything. I'm asking for the
server to *always* respond that something is not an inline blob item
*if* such a blob info item does reach the server (e.g. sent by not an
fbclient, or by an old fbclient talking to a newer server). Relying on
the client to be the only to know about an information item leads to
surprises and an inconsistent API.

So there are basically two situations:

1) The driver knows about such an information item and responds on its
own whether the blob handle points to an inline blob or a server-side blob
2) The client doesn't know about the information item, sends it to the
server, and the server says "no this is not an inline blob".

>   Also, driver that not uses fbclient should know if it received
> op_inline_blob for
> given blob_id, or not.

There are two levels at play here. The driver itself, which would know
it, and the user of a driver, which is not aware of the internals of the
driver and whether or not it supports inline blobs, but might be aware
of the information item to query this.

But I think just querying data transfer will be sufficient for my
verification purposes.

>> That might be an alternative for my purposes. Are those exposed in the
>> legacy API? If so, how?
>
>   Yes, it is implemented with new set of items (counters) for
> IAttachment::getInfo() (isc_database_info())
> See details at https://github.com/FirebirdSQL/firebird/pull/8310

Thanks!

Mark
--
Mark Rotteveel