27 Sep
2009
27 Sep
'09
4 a.m.
Just checking out the new 2.0 enterprise XWiki, great job! I'm just
wondering why you are using hsqldb in the standalone version rather
than h2 (http://www.h2database.com/html/main.html). H2 is in pretty
much every way an improved version over hsql and I've been very
impressed with its speed. Have you considered switching over and if
you decided against it, I'd be interested in hearing the reasons. If
you haven't considered it yet, I'll open an issue for it.
Kalle
27 Sep
27 Sep
6:11 a.m.
Kalle Korhonen wrote:
Just checking out the new 2.0 enterprise XWiki, great
job! I'm just
wondering why you are using hsqldb in the standalone version rather
than h2 (http://www.h2database.com/html/main.html). H2 is in pretty
much every way an improved version over hsql and I've been very
impressed with its speed. Have you considered switching over and if
you decided against it, I'd be interested in hearing the reasons. If
you haven't considered it yet, I'll open an issue for it.
This is the first time I hear about it. Looking a bit on its site, I
think that this is a good candidate for replacing hsql as the default
database (Derby is the other one). There is only one problem I can see
with it: choosing the right hibernate dialect. On the H2 documentation,
they warn that the official H2Dialect is buggy (how?), but that the hsql
dialect can be used.
Somebody will have to test it and see if there are any problems, and if
any speed improvement is noticeable.
Please feel free to open an issue, patches welcome :)
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
6:20 a.m.
Sergiu Dumitriu wrote:
Kalle Korhonen wrote:
One nice feature I spotted: native support for clustering.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Just checking out the new 2.0 enterprise XWiki,
great job! I'm just
wondering why you are using hsqldb in the standalone version rather
than h2 (http://www.h2database.com/html/main.html). H2 is in pretty
much every way an improved version over hsql and I've been very
impressed with its speed. Have you considered switching over and if
you decided against it, I'd be interested in hearing the reasons. If
you haven't considered it yet, I'll open an issue for it.
This is the first time I hear about it. Looking a bit on its site, I
think that this is a good candidate for replacing hsql as the default
database (Derby is the other one). There is only one problem I can see
with it: choosing the right hibernate dialect. On the H2 documentation,
they warn that the official H2Dialect is buggy (how?), but that the hsql
dialect can be used.
Somebody will have to test it and see if there are any problems, and if
any speed improvement is noticeable.
Please feel free to open an issue, patches welcome :)
7:28 a.m.
On Sat, Sep 26, 2009 at 9:11 PM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
This is the first time I hear about it. Looking a bit
on its site, I
think that this is a good candidate for replacing hsql as the default
database (Derby is the other one). There is only one problem I can see
with it: choosing the right hibernate dialect. On the H2 documentation,
they warn that the official H2Dialect is buggy (how?), but that the hsql
dialect can be used.
Ok. There are a few open issues still on Hibernate's side, but I think
the warning is kind of old. Though on H2's site they say it works with
hsql dialect as well, I wouldn't use it - that gives more problems
than solves. I've been using H2Dialect intensively and it has worked
in my application that contains some fairly complex queries without
any problems. They claim H2 performs much better than either hsql or
Derby in most situations and I can assert the claim - I had verified
it with my db tests (mostly related to write and transaction
performance) running against all three databases, and my results were
similar to what they mention at
http://www.h2database.com/html/performance.html.
Kalle
8:23 a.m.
On Sat, Sep 26, 2009 at 9:20 PM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
http://groups.google.com/group/google-appengine-java/web/will-it-play-in-ap…
One nice feature I spotted: native support for clustering.
IMHO, given the many things Xwiki plans to do, and limited time and
resources, I don't think this would be worth a lot of effort unless it had
some bigger payoff. Seems like anybody wanting better performance would just
move to mysql and not use a java database at all.
However, in addition to the clustering scenario, one area where a different
"native" database might be useful would be for supporting Xwiki on
"cloud"
platforms like google app engine.
Last time this was brought up
http://lists.xwiki.org/pipermail/users/2009-July/016817.html the issue was
Hibernate itself
On Wed, Jul 22, 2009 at 12:07 PM, Ludovic Dubost
<ludovic at xwiki.org>
wrote:
I have a
prototype of XWIki partially working with some changes on app
engine http://xwiki1.appspot.com/bin/view/Main/
I've made all the servlet / jvm part work as well as the cache subsystem.
The main missing piece is a real storage with support for querying.
Ludovic -- thanks for the reply. That looks quite promising. I guess the
"real storage" issue is caused by this limitation:
> You cannot currently use Hibernate directly. The
differences between the
> App Engine datastore and SQL were too great to get the standard Hibernate
up
> and running under App Engine. App Engine does
support JDO and JPA, so you
> may be able to convert your Hibernate code to use one of these ORM
> interfaces.
Also, with attachments stored in the db, large documents, or lots of
documents, what happens to memory size and performance with respect to
"large result sets":
http://www.h2database.com/html/performance.html states
Version 1.1.114 (2009-06-01) was used for the test. For simpler operations,
the performance of H2 is about the same as for HSQLDB.
For more complex
queries, the query optimizer is very important. However H2 is not very fast
in every case, certain kind of queries may still be slow. One situation
where is H2 is slow is large result sets, because they are buffered to disk
if more than a certain number of records are returned. The advantage of
buffering is, there is no limit on the result set size. The open/close time
is almost fixed, because of the file locking protocol: the engine waits some
time after opening a database to ensure the database files are not opened by
another process.
-- Niels
http://nielsmayer.com
11:39 a.m.
Sergiu Dumitriu schrieb:
There is only one problem I can see
with it: choosing the right hibernate dialect. On the H2 documentation,
they warn that the official H2Dialect is buggy (how?), but that the hsql
dialect can be used.
The H2Dialect is still broken; if you try to use it, you'll get
exceptions when Hibernate tries to create the tables. Just use the HSQL
dialect.
All in all, it should be at most half an hour for someone who knows
XWiki to replace one with the other. The major advantage of H2 over HSQL
is not speed but H2 is under development while HSQL is pretty much dead.
Regards,
--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://darkviews.blogspot.com/ http://www.pdark.de/
29 Sep
29 Sep
7:19 p.m.
On Sun, Sep 27, 2009 at 2:39 AM, Aaron Digulla <digulla(a)hepe.com> wrote:
The H2Dialect is still broken; if you try to use it,
you'll get
exceptions when Hibernate tries to create the tables. Just use the HSQL
dialect.
Table creation has worked for me with H2Dialect with latest Hibernate ok.
All in all, it should be at most half an hour for
someone who knows
XWiki to replace one with the other. The major advantage of H2 over HSQL
is not speed but H2 is under development while HSQL is pretty much dead.
Agree, but I've had several cases where H2 has turned out to be way
faster (DATEDIFF for example). Yes, it's easy to replace. H2 should be
just seen as version two of hsqldb (as the name implies) rather than a
completely different database though it's not completely backwards
compatible (but you can still use e.g. hsql dialect with h2).
Kalle
5519
days inactive
5521
days old
6 comments
4 participants
participants (4)
-
Aaron Digulla -
Kalle Korhonen -
Niels Mayer -
Sergiu Dumitriu