https://bugs.freedesktop.org/show_bug.cgi?id=38811
--- Comment #15 from dacm <[email protected]> 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. _______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
