[Libreoffice-bugs] [Bug 38811] [EasyHack] default to SQLite not HSQLDB in Base

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=38811

--- Comment #17 from dacm <dacmemail at gmail.com> 2012-04-11 01:01:32 PDT ---
(In reply to comment #16)
@Björn 
I certainly apologize for the off-topic nature of my comments above, and
particularly the "sour grapes" comment, which I retract as insignificant to the
overall situation. Please feel free to delete any of my inputs (here and there)
as necessary. That entire diatribe was crafted specifically to pour cold-water
on would-be developers as they consider their role in coding a perceived
regression of LO Base. But after a full day of reading the mailing lists, I do
understand the desperate situation for LO Base. I will not attempt to dispel
the reasoning I encountered because the desperation of the situation leaves
most reality-checks untenable. Something as glaring as the dying nature of
desktop-bound code (C++) relative to rich internet-capable apps (html5, and the
predecessors including Java, Flash and Silverlight) is simply not appropriate
for LO discussion today. That's quite understandable.

For those developers that may be interested in this "easy hack" challenge, it
is an unfortunate consequence of a rather limited talent pool, that we now find
ourselves begging for relief in the form of a Base regression. We certainly
prefer to call it an "enhancement" because it will (I'm convinced) pave the way
for necessary bug fixes and even improvements to LO Base over the long haul.
Because quite frankly, LO Base has been unable to attract and/or retain coders
with the necessary skills to tackle C++ and Java combined with an acute
knowledge of databases. That's understandable considering that Base is in the
(buggy) shape its in today due to the inability of the original Base (Sun)
developers to code, document and properly debug this trio. And perhaps
particularly so with respect to an in-process (JVM; embedded mode) Java
database engine. Reasonable attempts to rectify the situation have even
exacerbated the situation (bugs).

So given the realities, it is with grave apprehension as a user and
support-volunteer that I grant my own blessings for SQLite, as the default
database engine in Base. But only because it has the potential to save Base as
a component of LO. I will continue to steer users away from "embedded
databases" in production environments in general. And I still believe this
dumbed-down, programmer's engine is unworthy of a modern, end-user, front-end
like Base -- such that LO would be better-off disabling the 'embedded database'
option with Base than to embrace such functional regression. But I must admit,
the average user will never even use Base without a default (bundled) engine,
and perhaps even an all-in-one .odb database option for smaller mail-merge type
projects. Eventually, I think it would be advantageous to offer a portable
'split' file configuration in the name of stability, because single-file
stability is an issue even with the vast resources of MS Access 2010 -- which
is replete with official language warning about the stability of a single-file
database -- so much so that it sports a feature to 'split' the components into
separate front-end and back-end files "for proper stability." 

Despite the unbelievable ignorance I've encountered today in the LO mailing
lists among devs, designers, documenters and steering-committee leadership with
respect to the presumed adequacy of SQLite relative to HSQLDB 2.x, I do agree
that SQLite is a necessary evil in the future of LO Base. So I respectfully
join Björn and the LO team in the plea for code as necessary to integrate
SQLite as a default Base engine. The future of LO Base "unfortunately" rests in
your hands.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.