[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] document control

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] document control
Date: Sun, 10 Oct 2004 19:19:19 +0200
User-agent: Mutt/

> I have added some columns to gmBlobs.doc_med for
> document control -- keeping track of who's
> seen what, what need's to be sent, etc.
I wonder if those should be in doc_med or some table
*linking* to doc_med - certainly haven't looked at it yet,

However, this needs to be discussed and decided *BEFORE*
changing (it can be changed if there is good reason !)
because we have LIVE INSTALLATIONS of this out there.

> The idea is to have messaging daemons on the server which watch this
> table, and transmit/receive documents as required.
I would certainly not intermingle the "live" messaging tables
that are being watched with the "permanent storage" tables of
the data. One reason is that consistently dumping a "permanent
storage" table is far easier than a live, always-changing
documents table that is under constant watch.

> I've notices this duplicates some of the work in gmMeasurements.sql
> for path. results. However path results are documents too
No, they are values...

=f course, my statement is just as wrong as yours - fact is
that path results *appear* to be as documents to you while they
*appear* to be values to me. In fact, after sending "your"
(PIT) documents through Horst's PIT parser they will end up as
"my" values.

IOW, if the path results *appear* to be a document - store them
in the document tables. If the appear to be values put them in
the measurements tables.

Eg. a document present *information* while values present

> we should fold this into a single framework.
Not without good further thought.

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

[Prev in Thread] Current Thread [Next in Thread]