dhis2-devs team mailing list archive

[Lars Helge Øverland <larshelge@xxxxxxxxx>]

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


OK we are using an Enum to store the type. Hibernate maps this to a binary
field in the db as default but it seems its possible to map it to an int or
varchar field. We could do that.

Lars