- Also, use original verifiedAt date for emails. These users only have
newly created accounts/emails because of our blunder. Their nodes
should reflect when they became members/verified their emails.
We have to figure out if `mergeRels: true` is actually avoiding
duplicate relationships 🤔.
Before:
(l1)-[:IS_IN]->(l2)
(l1)-[:IS_IN]->(l3)
After:
(l1)-[:IS_IN]->(new)
(l1)-[:IS_IN]->(new)
- create command should be run with --date-format to be more human
readable, and --template-file to use our template instead of migrate's
default
- rename migrations
- rename createdAt to migratedAt to remove ambiguity
- do not merge relationships for Location nodes as we don't want to
create duplicate relationships
- use singular locationId as it's iterating one at a time
- having duplicate Location nodes in the production database blocks us
from adding a unique constraint, so that Locations are not created
which have the same id.
Implement a migration to merge duplicate user accounts with reactive
programming. Those duplicate user accounts existed, because around 40
users have decided to register again while we experienced a bug
related to normalized emails in our database.
