[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/1.3.22.1i |
> 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,
though.
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
*data*.
> IMHO
> we should fold this into a single framework.
Not without good further thought.
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346