[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-bugs] <bug>: trying to merge doubled patients
From: |
Karsten Hilbert |
Subject: |
Re: [Gnumed-bugs] <bug>: trying to merge doubled patients |
Date: |
Wed, 20 Mar 2013 12:31:12 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Hello Marc,
thanks for your report.
> user comment : trying to merge doubled patients
>
> client version: 1.2.8
This is one of the many ways merging patients can fail:
> 2013-03-14 19:04:23 WARNING gm.person
> (/usr/share/gnumed/Gnumed/business/gmPerson.py::assimilate_identity() #776):
> identity [1109] is about to assimilate identity [1310]
> 2013-03-14 19:04:23 ERROR gm.db
> (/usr/share/gnumed/Gnumed/pycommon/gmPG2.py::run_rw_queries() #1266): error
> running RW query
...
> IntegrityError: duplicate key value violates unique constraint
> "lnk_identity2comm_id_identity_key"
> DETAIL: Key (fk_identity, url)=(1109, <redacted>) already exists.
In this particular case the two patients have got the same
cell phone number (of course, they are the same patient! :-)
This sort of thing cannot be easily be solved in a
programmatically generic way without extensive schema
crawling and lots of business rules knowledge (Syan once
attempted such a thing).
This is also the reason why it is non-trivial to implement
an export-patient -> import-patient idempotent script.
Now, you couldn't care less about such technical vagaries,
all you want is merge those patients :-) They quick way
out for you is to activate either of patient 1109 or 1310
and edit (remove) the cell phone number on either of them
(hint: preferably prepend "old: " to the number string on
the to-be-merged patient 1310). That will get you around
this problem.
I did install a partial solution to this into the 1.3.next
code at any rate.
Karsten
--
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346