dhis2-devs team mailing list archive

[Lars Helge Øverland <larshelge@xxxxxxxxx>]

I have

- updated to the latest H2 version
- created a new H2 demo database and uploaded to dhis2.org
- changed the report table dimension type property to varchar

Lars

2010/4/13 Bob Jolliffe <bobjolliffe@xxxxxxxxx>:
> 2010/4/12 Lars Helge Øverland <larshelge@xxxxxxxxx>:
>>
>>
>> 2010/4/12 Bob Jolliffe <bobjolliffe@xxxxxxxxx>
>>>
>>> I had a go at this earlier with reasonable success.  You have to make
>>> an uncompressed pg dump with insert statements (these are both
>>> optional parametrs to pg_dump).  Some very slight adjustment to the
>>> structural metadata - I'll document later if people are interested -
>>> and then tried to import data.
>>>
>>> Only one snag - pg has its own peculiar way of handling binary strings
>>> (bytea fields) which h2 doesn't emulate.  Can't blame h2 too much -
>>> what pg does is a bid weird.
>>>
>>> This affects systemsettings, usersettings and reportsettings.
>>>
>>> Other than that I imported 1.5 million datavalues and associated
>>> dataelements, orgunits etc.
>>>
>>> The h2 guys are aware of the bytea compatibility problem and have the
>>> issue roadmapped - apparently they will bump it if it something people
>>> request.  I guess I should request.
>>>
>>> If I was really pushed I could write a script to find all the binary
>>> strings in the pg dump and try to convert them to something h2 is
>>> happy with.
>>>
>>> Having said that, I think all the places where we currently use binary
>>> strings are really unnecessary (storing evil java serialized objects)
>>> which I think have a historical rationale.  It should be relatively
>>> easy and desirable to change these - particularly as we also want to
>>> represent these things in xml - but we'd have to consider the effect
>>> on compatibility with legacy dhis databases which have the blobs.  I
>>> guess we'd need an upgrade script of some sort.
>>>
>>> So the prognosis is good but not quite seamless yet.
>>>
>>> Cheers
>>
>> This is great news. The system settings should def be no show-stopper here.
>> First they could simply be omitted as they probably will be set individually
>> anyway, second we could migrate to string as we have never really used
>> objects as settings.
>
> Hi Lars
>
> True.  system settings should be least disruptive.  Sorry I meant
> reporttable (rather than report setting!).   We are using a serialized
> java object to represent the dimension type which also seems a bit
> strange.  How do (non java) db clients like excel deal with these?
> I'll have another look tomorrow, but you will know better the
> rationale.  I'm guessing its related to the whole casting thing that
> we are doing with dimensions.
>
> Cheers
> Bob
>
>> Lars
>>
>