Storing/extracting embedded db within .odb

[Andrzej J. R. Hunt]

On Tue, 2013-07-09 at 15:59 +0200, Lionel Elie Mamane wrote:
On Mon, Jul 08, 2013 at 03:19:49PM +0100, Andrzej J. R. Hunt wrote:
> 
> > W.r.t. to the location of the extracted firebird db: would an appropriate naming scheme be to have
> > e.g. ~foo.odb.fdb#  for a foo.odb (in the same directory) similarly to the lock files that are
> > created? (This could also allow for better recovery should we end up with similar corruption
> > as is apparently happening with HSQLDB if there is a complete
> > separate db.)
> 
> It is a temporary file. I'd stick it in $TMPDIR (or the platform
> equivalent). Surely LibreOffice already has a platform abstraction
> utility function to find where to put temporary files.
> 
That was my original plan, however that would require writing the whole db back to the .odb every
time there is a change. If there were a file in the same directory instead we could potentially only
have to extract the db at startup and write it back into the .odb at shutdown (which means we can
ensure that the .fdb is in a good state by shutting down FB first) -- if we crash (lose power/etc.) in
the meantime the local file could then be used to restore the database (alternatively the location
of the temp file could be stored, but that would be more complicated to do I think).

On Tue, 2013-07-09 at 16:14 +0200, Lionel Elie Mamane wrote:
> On Tue, Jul 09, 2013 at 11:25:58AM +0100, Andrzej J. R. Hunt wrote:
> 
> > On further thought this seems best and is what I'll try to implement
> > -- for versioning information and other db properties I'll use the
> > same database/properties file which hsqldb based .odb files use,
> 
> The name of that file, its format, etc is decided by HSQLDB, not by
> LibreOffice. It is a HSQLDB file, not a LibreOffice file. Unless you
> have a compelling reason to give it the same name for
> embedded-Firebird ODBs, I'd rather you didn't. Actually, I don't
> completely understand what information you want to stick there
> anyway... Could you please enlighten me? If it is
> LibreOffice-specific, it sounds like it should be in the content.xml,
> not any extra separate file.
It seems I misunderstood the origin of the file -- having things in xml
does make more sense.


> > store the db itself as database/database.fdb. It shouldn't be too
> > hard to have the same driver load an external fdb file and configure
> > this using the properties file (some users are requesting this)
> 
> Indeed, it would be rather a pity to have this driver not be able to
> access an external database. But *please* don't configure that with
> any internal properties file, but configure it through the sdbc://
> URL! This allows also to make a SDBC connection "disconnected" from
> any .odb file, and this is how *all* our drivers do it.
Yes, I'll do that then . Is it worth emulating the hsqldb
driver structure whereby the embedded driver only deals with the .odb
specifics, and then delegates to the firebird driver to actually connect
to firebird itself? I guess that's not particularly necessary here given
we're not reusing a generic (jdbc in hsqldb's case) driver.

I.e. we could have an sdbc firebird driver which can deal with an external
file (possibly even a remote db, need to look into the details), and an
Embedded driver which extracts the db from a .odb and then delegates to
the firebird driver? (This embedded driver could then be used should
anyone want to use any other db's as an embedded db.)

The code dealing with extracting / storing the db is pretty small though
(40 lines for extraction so far + a bit for determining the path which
I've not done yet -- all untested though as of yet) -- so I could continue
with things as they are now and potentially leave the splitting for later
(or as an Easyhack?).

Cheers,

	Andrzej