Since this discussion moved from roadmap to import-export and then interchange formats... lemme add something to chew for on import-export.
Why aren't we using a diff-based import-export?? Suppose I already have an exported file and the new export file only should contain the new values, we can generate only the changed values in the export process. Definitely reduces time/ file size for places where import-export will be used monthly/weekly. Has anyone thought of object serialization?? Where we could serialize objects and move it to new places... A radical and stupid way, but may be useful for GIS import-export, where the dxf format may fall short on representing sharable geographic information. Disease surveillance on the CBHS may be one candidate... --- Regards, Saptarshi PURKAYASTHA Director R & D, HISP India Health Information Systems Programme My Tech Blog: http://sunnytalkstech.blogspot.com You Live by CHOICE, Not by CHANCE 2009/4/24 Bob Jolliffe <[email protected]> > 2009/4/23 Lars Helge Øverland <[email protected]>: > > > >> > >> 6 complicates the current import strategy where objects get imported "on > >> the fly" without temporary storage, maybe we can put this on hold. > > > > Actually this holds for 5 as well... > > > > I'll have to look at this more closely - though I know you will have a > better idea of what is going on. In principle it shouldn't really > matter. All that's happening in 5 is that we import a <Period> object > (on the fly, in its entirety or what have you). Then we just use the > inherited periodID attribute as we import all the contained > dataValues. I am not seeing how this would be fundamentally > different. Could be I'm just tired and in need of a beer ... > > Cheers > Bob >
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
