[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] nitpick misspelling in saved SQL query
From: |
Karsten Hilbert |
Subject: |
Re: [Gnumed-devel] nitpick misspelling in saved SQL query |
Date: |
Thu, 31 Dec 2009 11:47:07 +0100 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
On Wed, Dec 30, 2009 at 08:24:15PM -0800, Jim Busser wrote:
> One of the queries is
>
> patients whose narrative constains a certain coded term
>
> --> "constains" should be "contains"
will fix
> But I am now wondering about how revision of SQL content is handled in the
> scripts.
It depends on the circumstances.
In this case I will
a) NOT issue a fixup script for > v12 since it is not at all
fatal and people can fix it locally if they wan to
b) include a fixup with v12 which will UPDATE the row
thereby correcting the spelling mistake
> Whereas I know that upgrades can import *new* data, in cases such as
>
> - the above correction
> - the Current Medication List template, which you indicated you revised
>
> will re-upgrading a v11 into the most-current v12 import
> only the fixed medication template, on account of it being
> (from the point of view of v11) "new"
That is correct.
> whereas the fix in the
> name of "contains" would be excluded if its bootstrap
> resided at a level prior to v11? Even if this particular
> query was only introduced since the most recent official
> release, the question is a meta-one regarding the alteration
> of content originally bootstrapped prior to the most recent
> release.
In most cases that's easy. Either it MUST be corrected in
released versions, too, or not. If so we will issue a fixup
script with the next database fixup release, say, v11.3:
that fixup script will be applied by
- the upgrade procedure from v10 to v11
- or the upgrade procedure from v11.x to v11.3
- or the upgrade procedure from v11.x to v12
such fixup scripts can typically be re-run any number of times w/o ill
effects
> Would you make a choice with respect to what might have been misspelt, as
> whether to
>
> (A)
> leave it as it originally was, in the original SQL script, and instead
> programming that record's name to be altered in the newer script or
>
> (B)
> delete it from the original iteration of the SQL in which it appeared, and
> provide it in the next official release v11->12 script? This would give
> anyone who had previously bootstrapped the originally-spelt version a second
> copy (containing the new spelling), and they could delete the older
> incorrectly-spelt one?
That depends on the exact nature of the issue. I've done
both in the past. A similar thing was that I left in the
"old" way of adding patients for one entire release cycle.
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346