[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 

> 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.

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]