reason: Rosie.js does not support promises. So for the time being, we
shall not use more than one `after` callback and we shall not use
buildList as it does not return a `Promise.all([])`. We have to ask the
maintainers of Rosie.js if they accept the breaking change of returning
a Promise always.
- 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.
