Re: FireBird/LibreOffice: fb_config/pkg-config, thread-safety, eager caching

On Fri, 2013-07-19 at 04:40 +0200, Lionel Elie Mamane wrote:

> 1) I notice that Debian has neither fb_config, nor fbembed.pc; are
>    these part of the upstream build (and then it is a bug in Debian
>    that they are not in the packages)? Do other distros have them?
I'm still looking into this. Upstream has fb_config, suse has
fbembed.pc, Gentoo and debian seem to have neither.

Each of those distros has flamerobin which builds against firebird -- it
seems to use the following in it's configure.in (at least in their
current master -- I haven't looked at the distro releases yet):

AC_SEARCH_LIBS([isc_attach_database], [fbclient fbembed], [],

which looks like it could be usable (this worked on my suse system which
also ships the fbembed.pc). However flamerobin also ships the firebird
headers in its sources -- here we'd probably have to check that the
headers are in fact present? I'll try and experiment to see how well the
above works.

> 2) This is a bit scary in the Debian package description of
>    libfbembed:
>
>     Contrary to libfbclient, libfbembed is not thread-safe.
>
>    Taking a quick look at e.g. OResultSet::ensureDataAvailable,
>    it is mutexed, but (as far as I understand) with a *different*
>    mutex for each instance (for each object). So this does not keep
>    multiple ResultSets from making parallel calls to non-thread-safe
>    libfbembed from different threads.
Yes, I'll probably have to have a mutex on the Connection then which all
the other objects use (I'm not entirely sure -- can we have multiple
files open independently in parallel withe each connection having its
own mutex, or does the entire driver need to have one mutex)?
> 3) You seem to have duplicated
>    connectivity/source/{inc,commontools}/propertyids.[hc]xx
>    in connectivity/source/drivers/firebird/propertyids.[hc]xx?
>
>    With the _same_ include guard?
These were already there when I started working on the Firebird driver
-- I'm trying to deduplicate anything that already exists elsewhere so
I'll look at this too. (I think this probably originally came from the
skeleton driver in odk/examples/DevelopersGuide/Database/DriverSkeleton/
).

> 4) OResultSet::m_sqlData: the driver caches the *whole* resultset? Oh
>    my... And not only that, it eagerly fetches the *whole* resultset?
>
>    That will *not* scale.
>
>    Does Firebird 3 support scrollable cursors?
>
>    I'm not actually sure any LibreOffice code really requires
>    scrollable cursors; it seems to me that when it detects that the
>    driver / database does not support that, it makes a *new* query
>    with "WHERE primary_key=VALUE" each time it wants to "go back"
>    (this happens in dbaccess/source/core/api/KeySet.cxx and
>    RowSetCache.cxx).
>
>    If FireBird can't support previous() et al, it could just throw an
>    SQLError when they are called?
>
>    If the LibreOffice detection logic is b0rken, we should fix
>    *that* rather than inefficiently fake in the driver capabilities
>    that the database does not have.
Firebird 3 does apparently support scrollable cursors but 2.5 doesn't --
I never realized that drivers were allowed to not support previous() --
I'll remove the local storage and see how things work out.

Cheers,

        Andrzej