[Autofill] Transfer cards' billing address id when deduping profiles.

Transfer cards' billing address id when deduping profiles.

A new billing_address_id field was recently added to CreditCard object
to reference a profile it uses as its billing address.

The deduping algo doesn't do anything about that field. This means it
is possible to dedupe (merge profile A into profile B, then delete A)
and have a credit card point to the GUID of profile A.

This CL uses an acyclic graph to keep track of the profiles merges and
uses it to update the billing address of the credit cards. The full
solution is described in this document:
https://docs.google.com/document/d/1Xg6CAWJCL6WZxv5v5cuoZt1UfQ4moKFDJScbf3Q8q2s/edit?usp=sharing

BUG=670477
TEST=DedupeProfiles_GuidsMergeMap
UpdateCardsBillingAddressReference
ApplyDedupingRoutine_CardsBillingAddressIdUpdated

Committed: https://crrev.com/3cd4e5505fe1f927ee2d7e6f482cfa2a4e8622bf
Cr-Commit-Position: refs/heads/master@{#436604}

[sebsg, 2016-12-02 19:49:10]

Patchset #1 (id:1) has been deleted

[sebsg, 2016-12-02 20:19:32]

Patchset #1 (id:20001) has been deleted

[sebsg, 2016-12-02 20:24:00]

Description was changed from

==========
[Autofill]WIP Transfer cards' billing address id when deduping profiles.

BUG=670477
==========

to

==========
A new billing_address_id field was recently added to credit_card object to
reference a profile it uses as it's billing address.

The deduping algo doesn't do anything about that field. This means it's possible
to dedupe (merge profile A into profile B, then delete A) and have a credit card
hold the GUID of profile A.

This CL ensures that the billing_address_id fields are updated during dedupe.

BUG=670477
==========

[sebsg, 2016-12-02 20:26:11]

Patchset #1 (id:40001) has been deleted

[sebsg, 2016-12-02 20:30:48]

sebsg@chromium.org changed reviewers:
+ mathp@chromium.org, rouslan@chromium.org

[sebsg, 2016-12-02 20:30:48]

Hi Rouslan and Math, PTAL?

[please use gerrit instead, 2016-12-02 20:47:19]

https://www.chromium.org/developers/contributing-code#TOC-Writing-change-list...

[please use gerrit instead, 2016-12-02 20:48:57]

Remove any confidential info from the design doc, publish it as
sebsg@chromium.org with public visibility, and link to it from your CL
description.

[sebsg, 2016-12-02 20:50:50]

Description was changed from

==========
A new billing_address_id field was recently added to credit_card object to
reference a profile it uses as it's billing address.

The deduping algo doesn't do anything about that field. This means it's possible
to dedupe (merge profile A into profile B, then delete A) and have a credit card
hold the GUID of profile A.

This CL ensures that the billing_address_id fields are updated during dedupe.

BUG=670477
==========

to

==========
Transfer cards' billing address id when deduping profiles.

A new billing_address_id field was recently added to credit_card object
to reference a profile it uses as it's billing address.

The deduping algo doesn't do anything about that field. This means it
is possible to dedupe (merge profile A into profile B, then delete A)
and have a credit card hold the GUID of profile A.

This CL ensures that the billing_address_id fields are updated during
dedupe.

BUG=670477
TEST=PersonalDataMangerTest
==========

[Mathieu, 2016-12-02 20:58:31]

Description was changed from

==========
Transfer cards' billing address id when deduping profiles.

A new billing_address_id field was recently added to credit_card object
to reference a profile it uses as it's billing address.

The deduping algo doesn't do anything about that field. This means it
is possible to dedupe (merge profile A into profile B, then delete A)
and have a credit card hold the GUID of profile A.

This CL ensures that the billing_address_id fields are updated during
dedupe.

BUG=670477
TEST=PersonalDataMangerTest
==========

to

==========
Transfer cards' billing address id when deduping profiles.

A new billing_address_id field was recently added to CreditCard object
to reference a profile it uses as its billing address.

The deduping algo doesn't do anything about that field. This means it
is possible to dedupe (merge profile A into profile B, then delete A)
and have a credit card hold the GUID of profile A.

This CL ensures that the billing_address_id fields are updated during
dedupe.

BUG=670477
TEST=PersonalDataMangerTest
==========

[Mathieu, 2016-12-02 20:58:51]

Description was changed from

==========
Transfer cards' billing address id when deduping profiles.

A new billing_address_id field was recently added to CreditCard object
to reference a profile it uses as its billing address.

The deduping algo doesn't do anything about that field. This means it
is possible to dedupe (merge profile A into profile B, then delete A)
and have a credit card hold the GUID of profile A.

This CL ensures that the billing_address_id fields are updated during
dedupe.

BUG=670477
TEST=PersonalDataMangerTest
==========

to

==========
Transfer cards' billing address id when deduping profiles.

A new billing_address_id field was recently added to CreditCard object
to reference a profile it uses as its billing address.

The deduping algo doesn't do anything about that field. This means it
is possible to dedupe (merge profile A into profile B, then delete A)
and have a credit card point to the GUID of profile A.

This CL ensures that the billing_address_id fields are updated during
dedupe.

BUG=670477
TEST=PersonalDataMangerTest
==========

[sebsg, 2016-12-02 21:09:43]

Description was changed from

==========
Transfer cards' billing address id when deduping profiles.

A new billing_address_id field was recently added to CreditCard object
to reference a profile it uses as its billing address.

The deduping algo doesn't do anything about that field. This means it
is possible to dedupe (merge profile A into profile B, then delete A)
and have a credit card point to the GUID of profile A.

This CL ensures that the billing_address_id fields are updated during
dedupe.

BUG=670477
TEST=PersonalDataMangerTest
==========

to

==========
Transfer cards' billing address id when deduping profiles.

A new billing_address_id field was recently added to CreditCard object
to reference a profile it uses as its billing address.

The deduping algo doesn't do anything about that field. This means it
is possible to dedupe (merge profile A into profile B, then delete A)
and have a credit card point to the GUID of profile A.

This CL uses an acyclic graph to keep track of the profiles merges and
uses it to update the billing address of the credit cards. The full
solution is described in this document:
https://docs.google.com/document/d/1Xg6CAWJCL6WZxv5v5cuoZt1UfQ4moKFDJScbf3Q8q...

BUG=670477
TEST=PersonalDataMangerTest
==========

[sebsg, 2016-12-02 21:10:10]

Description was changed from

==========
Transfer cards' billing address id when deduping profiles.

A new billing_address_id field was recently added to CreditCard object
to reference a profile it uses as its billing address.

The deduping algo doesn't do anything about that field. This means it
is possible to dedupe (merge profile A into profile B, then delete A)
and have a credit card point to the GUID of profile A.

This CL uses an acyclic graph to keep track of the profiles merges and
uses it to update the billing address of the credit cards. The full
solution is described in this document:
https://docs.google.com/document/d/1Xg6CAWJCL6WZxv5v5cuoZt1UfQ4moKFDJScbf3Q8q...

BUG=670477
TEST=PersonalDataMangerTest
==========

to

==========
Transfer cards' billing address id when deduping profiles.

A new billing_address_id field was recently added to CreditCard object
to reference a profile it uses as its billing address.

The deduping algo doesn't do anything about that field. This means it
is possible to dedupe (merge profile A into profile B, then delete A)
and have a credit card point to the GUID of profile A.

This CL uses an acyclic graph to keep track of the profiles merges and
uses it to update the billing address of the credit cards. The full
solution is described in this document:
https://docs.google.com/document/d/1Xg6CAWJCL6WZxv5v5cuoZt1UfQ4moKFDJScbf3Q8q...

BUG=670477
TEST=PersonalDataMangerTest
==========

[sebsg, 2016-12-02 21:11:16]

Description was changed from

==========
Transfer cards' billing address id when deduping profiles.

A new billing_address_id field was recently added to CreditCard object
to reference a profile it uses as its billing address.

The deduping algo doesn't do anything about that field. This means it
is possible to dedupe (merge profile A into profile B, then delete A)
and have a credit card point to the GUID of profile A.

This CL uses an acyclic graph to keep track of the profiles merges and
uses it to update the billing address of the credit cards. The full
solution is described in this document:
https://docs.google.com/document/d/1Xg6CAWJCL6WZxv5v5cuoZt1UfQ4moKFDJScbf3Q8q...

BUG=670477
TEST=PersonalDataMangerTest
==========

to

==========
Transfer cards' billing address id when deduping profiles.

A new billing_address_id field was recently added to CreditCard object
to reference a profile it uses as its billing address.

The deduping algo doesn't do anything about that field. This means it
is possible to dedupe (merge profile A into profile B, then delete A)
and have a credit card point to the GUID of profile A.

This CL uses an acyclic graph to keep track of the profiles merges and
uses it to update the billing address of the credit cards. The full
solution is described in this document:
https://docs.google.com/document/d/1Xg6CAWJCL6WZxv5v5cuoZt1UfQ4moKFDJScbf3Q8q...

BUG=670477
TEST=DedupeProfiles_GuidsMergeMap
UpdateCardsBillingAddressReference
ApplyDedupingRoutine_CardsBillingAddressIdUpdated
==========

[Mathieu, 2016-12-02 21:12:39]

mathp@chromium.org changed reviewers:
+ rogerm@chromium.org

[Mathieu, 2016-12-02 21:12:39]

lgtm, seems pretty straightforward but would love Roger to have a look

https://codereview.chromium.org/2533303007/diff/60001/components/autofill/cor...
File components/autofill/core/browser/personal_data_manager.cc (right):

https://codereview.chromium.org/2533303007/diff/60001/components/autofill/cor...
components/autofill/core/browser/personal_data_manager.cc:1793: // Keep track of
the merges to update cards billing address references.
Make the comment more specific to the reader: Keep track that
|profile_to_merge|'s GUID should now point to |existing_profile|'s GUID when
credit card billing address associations are updated.

https://codereview.chromium.org/2533303007/diff/60001/components/autofill/cor...
components/autofill/core/browser/personal_data_manager.cc:1818: for (auto&
credit_card : local_credit_cards_) {
The ASCII art that you have in the test would be useful here, too.

https://codereview.chromium.org/2533303007/diff/60001/components/autofill/cor...
components/autofill/core/browser/personal_data_manager.cc:1819: bool
was_modified = false;
nit: bring closer to the while loop

https://codereview.chromium.org/2533303007/diff/60001/components/autofill/cor...
components/autofill/core/browser/personal_data_manager.cc:1824: while
(guids_merge_map.count(credit_card->billing_address_id())) {
what if there is no billing_address_id? Should we just let this code handle it
implicitely or be more explicit about it? I vote explicit by adding a check in
the first lines of the for loop, above.

https://codereview.chromium.org/2533303007/diff/60001/components/autofill/cor...
components/autofill/core/browser/personal_data_manager.cc:1827:
guids_merge_map.at(credit_card->billing_address_id()));
what about guids_merge_map[credit_card->billing_address_id()]? It should be
equivalent to "at" here but I think we use [] mostly.

[Roger McFarlane (Chromium), 2016-12-02 21:23:05]

https://codereview.chromium.org/2533303007/diff/60001/components/autofill/cor...
File components/autofill/core/browser/personal_data_manager.cc (right):

https://codereview.chromium.org/2533303007/diff/60001/components/autofill/cor...
components/autofill/core/browser/personal_data_manager.cc:1824: while
(guids_merge_map.count(credit_card->billing_address_id())) {
the count() and the at() both do a map lookup. Maybe do the lookup once with
find and reuse the resulting iterator?

while (true) {
  auto it = guids_merge_map.find(credit_card->billing_address_id());
  if (it == lguilds_merge_map.end()) break;
  was_modified = true;
  credit_card->set_billing_address_id(it->second);
}

[sebsg, 2016-12-02 21:45:19]

Patchset #2 (id:80001) has been deleted

[sebsg, 2016-12-02 21:46:34]

Thanks, another look?

https://codereview.chromium.org/2533303007/diff/60001/components/autofill/cor...
File components/autofill/core/browser/personal_data_manager.cc (right):

https://codereview.chromium.org/2533303007/diff/60001/components/autofill/cor...
components/autofill/core/browser/personal_data_manager.cc:1793: // Keep track of
the merges to update cards billing address references.
On 2016/12/02 21:12:39, Mathieu Perreault wrote:
> Make the comment more specific to the reader: Keep track that
> |profile_to_merge|'s GUID should now point to |existing_profile|'s GUID when
> credit card billing address associations are updated.

Done.

https://codereview.chromium.org/2533303007/diff/60001/components/autofill/cor...
components/autofill/core/browser/personal_data_manager.cc:1818: for (auto&
credit_card : local_credit_cards_) {
On 2016/12/02 21:12:39, Mathieu Perreault wrote:
> The ASCII art that you have in the test would be useful here, too.

Done.

https://codereview.chromium.org/2533303007/diff/60001/components/autofill/cor...
components/autofill/core/browser/personal_data_manager.cc:1819: bool
was_modified = false;
On 2016/12/02 21:12:39, Mathieu Perreault wrote:
> nit: bring closer to the while loop

Done.

https://codereview.chromium.org/2533303007/diff/60001/components/autofill/cor...
components/autofill/core/browser/personal_data_manager.cc:1824: while
(guids_merge_map.count(credit_card->billing_address_id())) {
On 2016/12/02 21:23:05, Roger McFarlane (Chromium) wrote:
> the count() and the at() both do a map lookup. Maybe do the lookup once with
> find and reuse the resulting iterator?
> 
> while (true) {
>   auto it = guids_merge_map.find(credit_card->billing_address_id());
>   if (it == lguilds_merge_map.end()) break;
>   was_modified = true;
>   credit_card->set_billing_address_id(it->second);
> }

Sure, I thought the other way was more readable, but your suggestion is more
efficient.

https://codereview.chromium.org/2533303007/diff/60001/components/autofill/cor...
components/autofill/core/browser/personal_data_manager.cc:1824: while
(guids_merge_map.count(credit_card->billing_address_id())) {
On 2016/12/02 21:12:39, Mathieu Perreault wrote:
> what if there is no billing_address_id? Should we just let this code handle it
> implicitely or be more explicit about it? I vote explicit by adding a check in
> the first lines of the for loop, above.

Done.

https://codereview.chromium.org/2533303007/diff/60001/components/autofill/cor...
components/autofill/core/browser/personal_data_manager.cc:1827:
guids_merge_map.at(credit_card->billing_address_id()));
On 2016/12/02 21:12:39, Mathieu Perreault wrote:
> what about guids_merge_map[credit_card->billing_address_id()]? It should be
> equivalent to "at" here but I think we use [] mostly.

In this use case they would be equivalent, but I chose "at" because it's const.

[please use gerrit instead, 2016-12-05 11:52:02]

lgtm

https://codereview.chromium.org/2533303007/diff/100001/components/autofill/co...
File components/autofill/core/browser/personal_data_manager.cc (right):

https://codereview.chromium.org/2533303007/diff/100001/components/autofill/co...
components/autofill/core/browser/personal_data_manager.cc:1845: 
Put this statement here to avoid "unused var" warning:

(void)nb_guid_changes;

[please use gerrit instead, 2016-12-05 11:52:11]

The CQ bit was checked by rouslan@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-05 11:52:20]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-05 12:11:08]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-05 12:11:09]

Dry run: Try jobs failed on following builders:
  android_compile_dbg on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_comp...)

[sebsg, 2016-12-05 15:29:10]

The CQ bit was checked by sebsg@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-05 15:29:32]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-05 16:25:51]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-05 16:25:52]

Dry run: This issue passed the CQ dry run.

[sebsg, 2016-12-05 17:32:51]

The CQ bit was checked by sebsg@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-05 17:33:15]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-05 18:18:40]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-05 18:18:41]

Dry run: This issue passed the CQ dry run.

[sebsg, 2016-12-05 18:30:47]

Patchset #3 (id:120001) has been deleted

[sebsg, 2016-12-05 18:31:26]

Addressed Rouslan's comments plus added a safety break out of the loop. 

Roger, do I have your blessing? :)

https://codereview.chromium.org/2533303007/diff/100001/components/autofill/co...
File components/autofill/core/browser/personal_data_manager.cc (right):

https://codereview.chromium.org/2533303007/diff/100001/components/autofill/co...
components/autofill/core/browser/personal_data_manager.cc:1845: 
On 2016/12/05 11:52:02, rouslan wrote:
> Put this statement here to avoid "unused var" warning:
> 
> (void)nb_guid_changes;

Done.

[please use gerrit instead, 2016-12-05 18:36:09]

https://codereview.chromium.org/2533303007/diff/140001/components/autofill/co...
File components/autofill/core/browser/personal_data_manager.cc (right):

https://codereview.chromium.org/2533303007/diff/140001/components/autofill/co...
components/autofill/core/browser/personal_data_manager.cc:1819: /*  Here is an
example of what the graph might look like.
Don't we use // comments in C++?

https://codereview.chromium.org/2533303007/diff/140001/components/autofill/co...
components/autofill/core/browser/personal_data_manager.cc:1850:
(void)nb_guid_changes;
You don't need this now, because you switched from "DCHECK(nb_guid_changes <
1000)" to "if (nb_guid_changes > guids_merge_map.size())". This is used to avoid
"unused variable" warning. "DCHECK(nb_guid_changes < 1000)" would generate this
warning because it's pre-processed out of the code before compiling it. So the
compiler only sees the declaration of the variable, but not its usage.

[sebsg, 2016-12-05 18:46:22]

https://codereview.chromium.org/2533303007/diff/140001/components/autofill/co...
File components/autofill/core/browser/personal_data_manager.cc (right):

https://codereview.chromium.org/2533303007/diff/140001/components/autofill/co...
components/autofill/core/browser/personal_data_manager.cc:1819: /*  Here is an
example of what the graph might look like.
On 2016/12/05 18:36:09, rouslan wrote:
> Don't we use // comments in C++?

There is an issue with // comments and a line ending with \
It gave the multi-line comment warning and did not compile on the bots, that's
why I used the /* */ version.

https://codereview.chromium.org/2533303007/diff/140001/components/autofill/co...
components/autofill/core/browser/personal_data_manager.cc:1850:
(void)nb_guid_changes;
On 2016/12/05 18:36:09, rouslan wrote:
> You don't need this now, because you switched from "DCHECK(nb_guid_changes <
> 1000)" to "if (nb_guid_changes > guids_merge_map.size())". This is used to
avoid
> "unused variable" warning. "DCHECK(nb_guid_changes < 1000)" would generate
this
> warning because it's pre-processed out of the code before compiling it. So the
> compiler only sees the declaration of the variable, but not its usage.

Done.

[Roger McFarlane (Chromium), 2016-12-05 19:52:12]

https://codereview.chromium.org/2533303007/diff/160001/components/autofill/co...
File components/autofill/core/browser/personal_data_manager.cc (right):

https://codereview.chromium.org/2533303007/diff/160001/components/autofill/co...
components/autofill/core/browser/personal_data_manager.cc:1795:
guids_merge_map->insert(std::pair<std::string, std::string>(
emplace() ?

you could also keep the result and DCHECK

i.e.,

auto ib = guids_merge_map->insert/emplace(...)
DCHECK(ib.second);
(void)ib;

https://codereview.chromium.org/2533303007/diff/160001/components/autofill/co...
components/autofill/core/browser/personal_data_manager.cc:1846: NOTREACHED();
capture this in an UMA metric?

This is otherwise silent.

Also, should this break or return. was_modified is now true and the partial
change will be committed to the DB. Is that a reasonable outcome?

[sebsg, 2016-12-05 20:43:06]

The CQ bit was checked by sebsg@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-05 20:43:52]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-05 20:56:07]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-05 20:56:08]

Dry run: Try jobs failed on following builders:
  linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[sebsg, 2016-12-05 21:49:42]

Patchset #5 (id:180001) has been deleted

[sebsg, 2016-12-05 22:02:01]

The CQ bit was checked by sebsg@chromium.org to run a CQ dry run

[sebsg, 2016-12-05 22:02:24]

https://codereview.chromium.org/2533303007/diff/160001/components/autofill/co...
File components/autofill/core/browser/personal_data_manager.cc (right):

https://codereview.chromium.org/2533303007/diff/160001/components/autofill/co...
components/autofill/core/browser/personal_data_manager.cc:1795:
guids_merge_map->insert(std::pair<std::string, std::string>(
On 2016/12/05 19:52:12, Roger McFarlane (Chromium) wrote:
> emplace() ?
> 
> you could also keep the result and DCHECK
> 
> i.e.,
> 
> auto ib = guids_merge_map->insert/emplace(...)
> DCHECK(ib.second);
> (void)ib;

Seems like emplace is not supported :S

https://codereview.chromium.org/2533303007/diff/160001/components/autofill/co...
components/autofill/core/browser/personal_data_manager.cc:1846: NOTREACHED();
On 2016/12/05 19:52:12, Roger McFarlane (Chromium) wrote:
> capture this in an UMA metric?
> 
> This is otherwise silent.
> 
> Also, should this break or return. was_modified is now true and the partial
> change will be committed to the DB. Is that a reasonable outcome?

I don't think this metric will be checked often if at all :S WDYT?

I set back is_modified to false for cards in the inifinite loop. That will give
deterministic results.

Thanks!

[commit-bot: I haz the power, 2016-12-05 22:03:04]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-05 22:50:10]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-05 22:50:12]

Dry run: This issue passed the CQ dry run.

[Roger McFarlane (Chromium), 2016-12-06 15:25:54]

lgtm

[sebsg, 2016-12-06 15:32:22]

The CQ bit was checked by sebsg@chromium.org

[sebsg, 2016-12-06 15:32:23]

The patchset sent to the CQ was uploaded after l-g-t-m from mathp@chromium.org,
rouslan@chromium.org
Link to the patchset: https://codereview.chromium.org/2533303007/#ps200001
(title: "Addressed Roger's comment")

[commit-bot: I haz the power, 2016-12-06 15:32:43]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-06 15:37:10]

CQ is committing da patch.

Bot data: {"patchset_id": 200001, "attempt_start_ts": 1481038342800050,
"parent_rev": "e8440a923857c801b28fb0eec43fb2719adc0fd5", "commit_rev":
"70f1a15a4d973a7627a4fd169f67965ec874d115"}

[commit-bot: I haz the power, 2016-12-06 15:37:39]

Description was changed from

==========
Transfer cards' billing address id when deduping profiles.

A new billing_address_id field was recently added to CreditCard object
to reference a profile it uses as its billing address.

The deduping algo doesn't do anything about that field. This means it
is possible to dedupe (merge profile A into profile B, then delete A)
and have a credit card point to the GUID of profile A.

This CL uses an acyclic graph to keep track of the profiles merges and
uses it to update the billing address of the credit cards. The full
solution is described in this document:
https://docs.google.com/document/d/1Xg6CAWJCL6WZxv5v5cuoZt1UfQ4moKFDJScbf3Q8q...

BUG=670477
TEST=DedupeProfiles_GuidsMergeMap
UpdateCardsBillingAddressReference
ApplyDedupingRoutine_CardsBillingAddressIdUpdated
==========

to

==========
Transfer cards' billing address id when deduping profiles.

A new billing_address_id field was recently added to CreditCard object
to reference a profile it uses as its billing address.

The deduping algo doesn't do anything about that field. This means it
is possible to dedupe (merge profile A into profile B, then delete A)
and have a credit card point to the GUID of profile A.

This CL uses an acyclic graph to keep track of the profiles merges and
uses it to update the billing address of the credit cards. The full
solution is described in this document:
https://docs.google.com/document/d/1Xg6CAWJCL6WZxv5v5cuoZt1UfQ4moKFDJScbf3Q8q...

BUG=670477
TEST=DedupeProfiles_GuidsMergeMap
UpdateCardsBillingAddressReference
ApplyDedupingRoutine_CardsBillingAddressIdUpdated
==========

[commit-bot: I haz the power, 2016-12-06 15:37:41]

Committed patchset #5 (id:200001)

[commit-bot: I haz the power, 2016-12-06 15:40:31]

Description was changed from

==========
Transfer cards' billing address id when deduping profiles.

A new billing_address_id field was recently added to CreditCard object
to reference a profile it uses as its billing address.

The deduping algo doesn't do anything about that field. This means it
is possible to dedupe (merge profile A into profile B, then delete A)
and have a credit card point to the GUID of profile A.

This CL uses an acyclic graph to keep track of the profiles merges and
uses it to update the billing address of the credit cards. The full
solution is described in this document:
https://docs.google.com/document/d/1Xg6CAWJCL6WZxv5v5cuoZt1UfQ4moKFDJScbf3Q8q...

BUG=670477
TEST=DedupeProfiles_GuidsMergeMap
UpdateCardsBillingAddressReference
ApplyDedupingRoutine_CardsBillingAddressIdUpdated
==========

to

==========
Transfer cards' billing address id when deduping profiles.

A new billing_address_id field was recently added to CreditCard object
to reference a profile it uses as its billing address.

The deduping algo doesn't do anything about that field. This means it
is possible to dedupe (merge profile A into profile B, then delete A)
and have a credit card point to the GUID of profile A.

This CL uses an acyclic graph to keep track of the profiles merges and
uses it to update the billing address of the credit cards. The full
solution is described in this document:
https://docs.google.com/document/d/1Xg6CAWJCL6WZxv5v5cuoZt1UfQ4moKFDJScbf3Q8q...

BUG=670477
TEST=DedupeProfiles_GuidsMergeMap
UpdateCardsBillingAddressReference
ApplyDedupingRoutine_CardsBillingAddressIdUpdated

Committed: https://crrev.com/3cd4e5505fe1f927ee2d7e6f482cfa2a4e8622bf
Cr-Commit-Position: refs/heads/master@{#436604}
==========

[commit-bot: I haz the power, 2016-12-06 15:40:33]

Patchset 5 (id:??) landed as
https://crrev.com/3cd4e5505fe1f927ee2d7e6f482cfa2a4e8622bf
Cr-Commit-Position: refs/heads/master@{#436604}