FireBird/LibreOffice: fb_config/pkg-config, thread-safety, eager caching
Andrzej J. R. Hunt
andrzej at ahunt.org
Thu Jul 18 23:35:07 PDT 2013
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
> 2) This is a bit scary in the Debian package description of
> 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
> 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
> 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.
More information about the LibreOffice