Ismailtaktak / freemedforms

Automatically exported from code.google.com/p/freemedforms
Other
0 stars 0 forks source link

saved patient changes not reflected in patient search #230

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
search for any patient, open it and go to the identity editor.
Rename his e.g.last name to something else.
Save it with the "Save" icon.
now go back to the patient search UI.
The patient name has not changed.

Possible solution:
introduce IPatient::currentPatientDataChanged(QModelIndex index) signal, emit 
it when patient data changes, and connect it to the Patient search.

This signal could be used by many other widgets too, to reflect quickly updated 
data changes in the UI.

Original issue reported on code.google.com by christian.a.reiter@gmail.com on 3 Dec 2012 at 12:00

GoogleCodeExporter commented 9 years ago
Ok, the only thing to do is to use a QProxyModel in the patient selector 
instead of filtering the 'root' patientmodel. This has nothing to do with 
signals. To ensure, don't search a patient, select ARCHER, add him a second 
name and save, return the the search view -> saves done.

Original comment by eric.mae...@gmail.com on 3 Dec 2012 at 7:30

GoogleCodeExporter commented 9 years ago
Hm. This is one of the things where I think FMF is NOT really reliable. Just 
try to experiment a bit with renaming:
open a Patient with a dblclick on the selector. Rename his first/second/... 
name or change the title. Now press "save" on the toolbar:

Sometimes the Patient name in the uppar view is updated, sometimes not. 
Sometimes, whcn you change back to the patient selector, the name is updated, 
sometimes not...

Original comment by christian.a.reiter@gmail.com on 3 Dec 2012 at 10:06

GoogleCodeExporter commented 9 years ago
Yes that"s bacause I use the a sql filter on the patient model --> index get 
modified --> desync model/view/index. So I should use a proxymodel in the 
search view. I think this is the best. Now the problem of the memory/CPU cost 
is on the front side...

Comment two: if 5 MD use the same DB with 5 computers. One add a patient -> 
other will not have him. One change the name of a patient -> other does not 
have the modification...

Original comment by eric.mae...@gmail.com on 3 Dec 2012 at 10:13

GoogleCodeExporter commented 9 years ago
Oh, then everything is clear - I didnÄt get that info in your first answer. 
Ok, yes, a ProxyModel should do the filtering then for the searching, fully 
agree. I think the mem/cpu costs are not that important as constantly querying 
the database, especially when there are slower networks.
Additionally, patient searching is a thing that is used VERY often, so it 
should be as fast as possible: again prefer ProxyModel to sql query.

But: this does not explain the Not-Updating in the Patient bar, does it?

Original comment by christian.a.reiter@gmail.com on 3 Dec 2012 at 10:19

GoogleCodeExporter commented 9 years ago
Oh yes patientbar is connected to dataChanged() of the patientmodel. But if the 
index gone wrong -> no update
I'll try to add the proxymodel and make some tests.

Original comment by eric.mae...@gmail.com on 3 Dec 2012 at 10:22

GoogleCodeExporter commented 9 years ago
ah ok this explains it, yes.

Original comment by christian.a.reiter@gmail.com on 3 Dec 2012 at 10:39

GoogleCodeExporter commented 9 years ago
Code is pushed, I've done a BIG update of the workflow creating a 
Patients::PatientCore, etc...
Now all looks fine. Have some tests and tell me if you found bugs. Meanwhile, I 
close this issue.

Original comment by eric.mae...@gmail.com on 6 Dec 2012 at 1:37