Dupe improve custom data handling
authoreileen <emcnaughton@wikimedia.org>
Thu, 9 Apr 2020 05:58:31 +0000 (17:58 +1200)
committereileen <emcnaughton@wikimedia.org>
Mon, 13 Apr 2020 22:10:35 +0000 (10:10 +1200)
commitfe3b8caf207e6f44bec608512740b8d1c670e746
tree84edba38da3ac2043744768b09d2011c6d77234e
parent92fc8db8e72872195355661114141e8df8fd1fbb
Dupe improve custom data handling

The  current  custom data handling code does the  following

1) For normal single rows it first inserts a row. This has the impact of rendering the
update that follows meaningless (this was an intentional change). It then deletes the row.
Hence the upshot is simply that it deletes the row. A separate process transfers the custom
data for the row. In other words we are engaging in 3 queries with a fairly high chance of
causing deadlocks in order to just delete the row.

2) For single rows where the entity reference refers to the merged contact the row is
updated to refer to the merged contact (without the insert this works) and a further unnecessary delete follows

3) For custom groups supporting multiple rows the rows are updated to have the new entity id. An unnecessary delete follows.

This change only affects the first of these. I would like to, in a future PR, change UPDATE IGNORE to just UPDATE &
remove the unnecessary delete - with more testing.

Note that this does include a slight change of behaviour. Currently if ANY fields in a custom group
are transferred from one contact to another during merge the row is deleted (with all the custom fields in it).
However, if no fields in a set are deleted then the row is not deleted.

This felt like it was a bit short on consistency. If has a potential advantage from a DB size point of view (any
deleting is better than none) but it also increases the number of locking queries in a process that is fairly
prone to cause DB locks. Based on these considerations I didn't think it worth re-adding code complexity to
retain inconsistent deletion.

A note on tests - I pre-added a bunch of tests into _api3_ContactTest to cover the 3 scenarios above.
CRM/Core/DAO.php
CRM/Dedupe/Merger.php
tests/phpunit/CRM/Dedupe/MergerTest.php