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 <[email protected]>: > 2010/4/12 Lars Helge Øverland <[email protected]>: >> >> >> 2010/4/12 Bob Jolliffe <[email protected]> >>> >>> 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 >> > _______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
