Re: [Gnumed-devel] Backend dem.urb needs cleaner constraint

[Jim Busser]

On 2011-10-08, at 1:40 PM, Karsten Hilbert wrote:

> On 2011-10-08, at 1:55 PM, Karsten Hilbert wrote:
> 
>>> dem.state warrants to be
>>> 
>>>    "state_code_key" UNIQUE, btree (UPPER(code), UPPER(country))
>>> 
>>> 
>>> dem.street warrants to be
>>> 
>>>    "street_id_urb_key" UNIQUE, btree (id_urb, UPPER(name), UPPER(postcode))
>> 
>> Done.
> 
> On Fri, Oct 07, 2011 at 08:59:50PM -0700, Jim Busser wrote:
> 
>> Indexes:
>>    "urb_pkey" PRIMARY KEY, btree (id)
>>    "urb_id_state_key" UNIQUE, btree (id_state, postcode, name)
>>    "idx_dem_urb_id_state" btree (id_state)
>>    "idx_urb_names" btree (name)
>>    "idx_urb_zips" btree (postcode)
>> 
>> 
>> suggest
>> 
>>    "urb_id_state_key" UNIQUE, btree (id_state, postcode, name)
>> 
>> should better be
>> 
>>    "urb_id_state_key" UNIQUE, btree (id_state, UPPER(postcode), UPPER(name))
> 
> Done.
> 
> Its's going to be interesting who's going to be first for
> whom the upgrade fails because of this.

1. Should we expect this to be a problem and should we figure some 
auto-resolution (like with the LOINC situation though I did not yet test git)

        or since such an auto-solution requires an arbitrary decision of which 
values (matching on UPPER case) to keep vs reject should we leave this to the 
users and their IT support?

2. Does it warrant any heads-up to GNUmed announce?


3. When the user in future ignores a phrasewheel match (which I think matches 
case-insensitive) and would input a variant case for the same characters as are

        UPPER(existing street) or

        UPPER (existing postcode)

will the GUI link the matched-on-upper-case value to what already exists in the 
backend, or will it beep to the user, or ??