Re: LO / Firebird DB Integration

On 24/06/13 20:38, Jean-Pierre Ledure wrote:
> > I do not see any improvement with having to bundle hsqldb vs. having to bundle firebird.
> If Firebird becomes the default database in Base, it will not be a
> matter of bundling either HSQLDB or Firebird, but of bundling _both_ !
> Otherwise what about existing legacy databases ?
Not exactly: the plan would be to eventually have a parser that can
import an HSQLDB database, meaning HSQLDB itself can still be binned.
> > The main motivation for the switch was getting rid of java
> AFAIK the main issue in using a HSQLDB database embedded in the .odb
> file is that, when LO crashes, the chance is big that the database is
> destroyed: the recovery process does not recover that part of the file.
> Will it still be the case with an embedded Firebird database ?
I don't know enough of the background on this unfortunately, so can't
really comment in depth. I guess it depends on how robust the specific
database in use is and I haven't seen any reports of problems with
recovering FB databases. (This may also have something to do with the
overriding of Javas i/o in order to get hsqldb writing directly into an
odb file -- Firebird, at least for the moment, will be using an external
file which is then copied into the odb file, which would eliminate
issues in that transition.)
> In that context I invite interested people to read a.o. the thread
> published last monday on
> http://forum.openoffice.org/en/forum/viewtopic.php?f=13&t=62419 by DACM.
> An extract:
> > Unfortunately, the devs remain preoccupied with the embedded database
> > concept based on a default database engine. They're literally wasting
> > the summer trying to shoe-horn Firebird into Base as the default in
> > order to achieve yet another, single-file database (.odb), much like
> > we have today with HSQLDB. They don't seem to understand or
> > acknowledge that the user community has shelved the concept because
> > it is inherently unreliable (as confirmed by Microsoft
> > <http://www.techrepublic.com/blog/10things/10-reasons-to-split-an-access-database/1119>:
> > http://www.techrepublic.com/blog/10things/10-reasons-to-split-an-access-database/1119).
> > We've also moved beyond the idea of a default database with Base.
> > This actually free's the devs to eliminate internal Java dependencies
> > from the entire LibO/AOO code-base, perhaps with the exception of the
> > hooks necessary for external JDBC support.
>
> Have users been enough involved in the debate so far ?
If I've understood correctly the suggestion is to remove the "Create a
new database" option from the Base startup dialog (which creates the
embedded database) along with the associated embedded database loading
code (very little code in Base is embedded specific) in order to prevent
the use of embedded databases? This wouldn't lead to any advantage for
external db users, and would massively disadvantage embedded db users
(e.g. casual users like myself, possibly some more serious uses
requiring everything in one file, ...), so seems to be a bit of a
complete non-starter really (not to mention increased entry barrier for
new users, setup required for unit-testing, etc.).

Cheers,

    Andrzej