Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

contact id fix #5610

Merged
merged 4 commits into from
Jul 18, 2022
Merged

contact id fix #5610

merged 4 commits into from
Jul 18, 2022

Conversation

bradymiller
Copy link
Sponsor Member

fixes #5609

@bradymiller
Copy link
Sponsor Member Author

bradymiller commented Jul 17, 2022

@psoas and @adunsulag ,

Fixed bug where modifying a already existing address was creating a new contact entry.

When add a new address, it is still creating a new contact entry for same patient though (is this meant to happen or are all the contact_address entries for the same patient supposed to link to the same contact entry?).

@bradymiller
Copy link
Sponsor Member Author

just added another commit to deal with my above comment/question:
"When add a new address, it is still creating a new contact entry for same patient though (is this meant to happen or are all the contact_address entries for the same patient supposed to link to the same contact entry?)."

Not sure though if we are only allowing one contact per foreign table/id combination, so will need to await input before bringing this in.

@psoas
Copy link
Contributor

psoas commented Jul 17, 2022

@bradymiller @adunsulag
There should only be one contact table entry per foreign table/id combination.

@psoas
Copy link
Contributor

psoas commented Jul 17, 2022

@bradymiller @adunsulag
Also, I beleive the idea behind the ORDataObject is to not have to write individual queries.

I don't think that putting a query in there is the correct fix. I know there is a rush and stephen is driving cross country. I have to look at the code tonite after I take my kids to the zoo. It would probably take me a couple hours to figure it out. Unless Stephen gets to it before me.

Comment on lines -43 to 44
$this->_id = $id;
$this->id = $id;

Copy link
Sponsor Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep this is reason update was creating a new contact record.

Comment on lines 56 to 59
// if entry already exists in table, then set the id
$id = sqlQuery("SELECT `id` FROM `contact` WHERE `foreign_table_name` = ? AND `foreign_id` = ?", [$foreign_table_name, $foreign_id])['id'] ?? null;
if (!empty($id)) {
$this->id = $id;
Copy link
Sponsor Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bradymiller
Since the contact table is just for mapping what tables additional addresses are used and not for mapping each address entry then I don't see a recourse other than to validate if an existing mapping already exists and carry the id forward.

While this fix will work on updating an existing or adding a single new address, it will fail when adding more than one additional address when an existing contact doesn't already exist. Say new patient and adding several additional addresses on data entry.

This is because we build a array of records to save before we persist(I think an eye towards transaction). Since a contact map for the patient doesn't exist, then a new sequence is generated populating the records array(in memory) then persisted.
The contact id should be tested for and set in a property in contact service construct somehow.

I can fix this tonight if you want or we wait.

Copy link
Sponsor Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sjpadgett , noted that issue on multiple addresses on testing and think may have a solution (still testing it).

@bradymiller
Copy link
Sponsor Member Author

bradymiller commented Jul 17, 2022

Currently testing well and confirmed the addresses are all still sent in the fhir requests. Since not super confident on the strategy i used, will await further input before i bring this into codebase (gonna postpone 7.0.0 release until likely tues/wed).

@psoas
Copy link
Contributor

psoas commented Jul 18, 2022

@bradymiller @sjpadgett @adunsulag

Please see Contact ID Fix 2 #5611.

I did some modifications to Brady's fix. And, it tested well for me. Please consider it. It is not a lot of code, but it was a lot of time.

Copy link
Sponsor Member

@sjpadgett sjpadgett left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bradymiller
This is working well for me and achieves our goals. Unless @adunsulag has issue which the way this is done, I say merge and let's move on.

Thanks for the work.

@sjpadgett
Copy link
Sponsor Member

I'm going to merge this fix. I've tested add, delete, updates and views with good results.

@psoas I know what it is like to want to see your contribution to the end and your vision implemented however, we really need to move on and this fix, while maybe not the way you'd like to see it done, allows us to do that.
Still, if you want to take another approach then by all means we'll look at it. In the end this was a long road for you and a good job so, thanks.

@sjpadgett sjpadgett merged commit b9e0d54 into openemr:master Jul 18, 2022
@psoas
Copy link
Contributor

psoas commented Jul 18, 2022

@sjpadgett
After your last comment on my pull request, I realized that I tested for every case EXCEPT adding multiple new addresses when a contract table entry does not already exist for the patient. And, that is where my solution breaks.

I can't think of any other way to do it other than how Brady did it. All of my wasted time.

My addition, although not necessary for 7.0.0 release, could be useful for avoiding excess database writes. But, I don't know if that matters. Does it?

@sjpadgett
Copy link
Sponsor Member

All of my wasted time.

It is never a waste of time IMO. We all have our moments and can't catch everything. That is what peer review is all about and working as a team. So I suspect through all of this you've learned something. I know I do all the time.

But, I don't know if that matters. Does it?

I'd say it does and I'm sure you have additional development for your project where you can tune and address data management going forward.

I look forward to see what's next.

sjpadgett pushed a commit that referenced this pull request Jul 18, 2022
* contact id fix

* only allow 1 contact per foreign table name and foreign id

* getting closer

* minor fix

(cherry picked from commit b9e0d54)
@sjpadgett
Copy link
Sponsor Member

@bradymiller I cherry picked this to v7 branch. I'm not seeing anything else unless there's something else I can help with for release.

@bradymiller
Copy link
Sponsor Member Author

bradymiller commented Jul 18, 2022 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Contact Table Not Being Updated Correctly
3 participants