dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

Hi

Not good news.

2009/4/3 Lars Helge Øverland <larshelge@xxxxxxxxx>:
>
>
> I have looked at different alternatives for the embedded database in the
> lite version.
>
> - H2 is not working out so well. It seems the Hibernate H2Dialect is buggy.
> The H2 people tried to submit a patch but it didn't work so well. It's all
> explained here:
> http://opensource.atlassian.com/projects/hibernate/browse/HHH-3401 .
>
> What is weird is that all our unit tests run fine on H2 but I guess we
> haven't covered it all. I get problems e.g. on import for calculated data
> elements, which is mapped as a subclass of DataElement in Hibernate.

Yes I'd seen rumours that the H2Dialect was buggy, but hadn't hit any
problems before.  One of the reasons for looking at ...

> - Derby embedded looks as a good alternative, but unfortunately crashes at
> database creation time because "indicator" and "translation" (which are
> database table names in DHIS 2) are reserved words in Derby (doh). I don't
> feel like starting to rename the tables, any other suggestions?

Derby/javaDB.  Let me take a look now.  Though I am not sure how we
might get around the tablename/reserved word problem other than
renaming and refactoring which could be painful.

> - HSQLDB works fine with Hibernate, but the current 1.8 version does not
> support the multiple insert SQL syntax, which is used heavily in the import
> and datamart process. According to the roadmap this will be supported in the
> 1.9 version. The 1.9 Alpha 2 version was released on April 1, but it is not
> present in the maven repo and we shouldn't base ourselves on an alpha. Also,
> I don't feel like going for this one after reading this:
>
> "SQLDB has two main table types used for durable read-write data storage.
> The default MEMORY type stores all data changes to the disk in the form of a
> SQL script. During engine start up, these commands are executed and data is
> reconstructed into the memory. While this behavior is not suitable for very
> large tables, it provides highly regarded performance benefits and is easy
> to debug."

I don't think HSQLDB is a serious contender.  If we are looking for
something which is well supported and with "legs" then it probably has
to be javaDB.  Let me see what I can find out.

Regards
Bob

> Please help...
>
>
>
>