[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 #15 from dacm <dacmemail at gmail.com> 2012-04-09 16:38:16 PDT ---
I'm not sure what's really behind this push for SQLite as the default engine in
Base, but I can assure you that this move is viewed as a significant step
backwards in the Base support-community. The issues mentioned here are
completely irrelevant to Base users, and likely won't ease the development of
LibO Base. The average Base user is not informed enough to assess all options
before beginning a Base project, so the default must be flexible enough to meet
all of their expectations (ala MS Access). HSQLDB 2.x provides that
flexibility. SQLite does not.

Base is enhanced by the SQL standards-compliance found with HSQLDB as this
speeds the learning process. HSQLDB 2.x provides an excellent SQL features-set,
adequate for virtually all Base projects. And we find that many users actually
expect multi-user scalability as available with HSQLDB. These are all lost with
SQLite which bucks SQL-standards, lacks many SQL features, isn't scalable, and
has fallen woefully behind HSQLDB 2.x in terms of features and development
pace. These inadequacies will only widen and cause immediate support-headaches
as users are forced into tedious data-migration simply to achieve what HSQLDB
2.x offers out-of-the-box. 

Performance is not the primary issue as HSQLDB compares very closely with
SQLite in terms of speed. Besides, H2 (cousin of HSQLDB) has proven faster than
SQLite in read performance, so I suspect that Java's JIT compiler is actually
quite efficient. 
http://h2database.com/html/tutorial.html#android

All Base functions are affected by the power of the database engine including
Queries, Forms and Reports. For example, Base Forms are highly dependent on the
SQL feature-set supplied by the underlying database engine. The more functional
the engine, the more functional Forms can become. We already have users that
upgrade from the default HSQLDB 1.8 engine to HSQLDB 2.x for various functions
such as DATE MATH, GROUP_CONCAT, and user-defined CHECK constraints. This is a
relatively simple task given the upgrade automation provided by HSQLDB 2.x for
legacy HSQLDB 1.8 databases. But as most users start with the default, they'll
be much more quickly disappointed with SQLite, which starts with less function
than the current default and then requires tedious data-migration to adopt a
more comprehensive engine like HSQLDB 2.x!

Base users currently have a default database engine that scales from
single-user in the seamless 'embedded' mode, to multi-user in 'server mode' --
without engaging in data migration. This is a key feature among users making
the move from MS Access. Why would we want to give up this feature to adopt
SQLite? 

Is this really about ease of development for LibreOffice programmers? I doubt
it. The necessary hooks for JDBC compatibility are already available in
LibreOffice. And the significant work on HSQLDB 2.x integration is already
complete. I suspect that the "unfortunate" role of Java in this discussion has
more to do with sour-grapes/politics (Oracle/Sun) than on the purported reach
of LibreOffice Base into all relevant platforms. If you're actually targeting a
platform that doesn't support Java, then it's probably irrelevant to the vast
majority of users. Why dumb-down a product for the exclusive benefit of a
handful of users? And I suspect that Java has been implemented much more
uniformly across supported platforms than the native code written by SQLite
developers, as mentioned by a previous poster in this comment-thread. 

BTW, H2 would be another excellent choice as the Base default. The emphasis on
HSQLDB 2.x here simply recognizes the momentum and the work already done on
HSQLDB 2.x integration. Both of these Java engines have the footprint,
features, scalability and speed necessary to maximize Base through the default
engine.

In summary, SQLite as the default engine will effectively reduce the function
and flexibility of Base projects with particular impact on Queries, Forms and
Reports while eliminating the expected (migration-free) path into multi-user
environments such as MS Access provides, all due to the lack of features and
function of SQLite relative to HSQLDB 2.x. It just doesn't make any sense.

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