On Mon, Feb 19, 2007 at 07:04:35AM +1100, Tim Churches wrote: > >> surprisingly tricky and fragile). But it does support dataset > >> versioning, so that the latest version of source data can be loaded into > >> a new dataset in the background while users continue to use an existing > >> dataset, and when the new load has completely it is transparently used > >> for all new analysis sessions. > > Isn't that what transactions are all about in an MVCC > > database ? > > Yes, but it doesn't use PostgreSQL (our data collection facility, NetEpi > Collection, uses PostgreSQL). Oh, I thought since NetEpi does the other does, too. But MVCC isn't limited to PostgreSQL so there was still a chance. Also, it would only support old and new and when new became committed old wouldn't be accessible (readily) anymore.
> Also, the versioning is at the level of > entire datasets (equivalent to tables in an SQL database, more or less). Which just means the scope of the transaction would have to be set appropriately. > >> would be harder, but possible - maybe a few weeks work. It can certainly > >> load data directly from a database back-end, although some queries to > >> flatten the data appropriately might be needed. > > This might be achievable with a few flattening and/or even > > materialized views inbetween the NetEpi code and the OpenMRS > > schema. > > Yes, but would need to be able to use the OpenMRS concept dictionary and > other metadata to be able to flatten the OpenMRS tables/entities stored > in EAV form, and also do statically defined joins between those and > other conventional tables in OpenMRS. All of which would still be available for access despite the views layer. But it's work which doesn't get done by itself, yes. > No, we need the data in computable form OK, that kills the easy solution. Or it might not. If you don't blend both sources of information (background image and user input) but rather keep them separate and blend on display/printing you'd still have the computable user input. The drawback is that it lacks any metadata (apart from which form it belongs to) as all the metadata would be encoded in the *location* of what the user typed. Which in itself just *might* lend itself to an OCR-like solution where a mask image is overlaid onto the data thereby adding metadata to it. > hand-written forms using that, but gee, an open source solution would be > nice. Suggestions very welcome. If I had any GNUmed would have an interface for it :-( Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
