migration-scripts icon indicating copy to clipboard operation
migration-scripts copied to clipboard

Data of relations in some cases not migrated

Open GregorSondermeier opened this issue 1 year ago • 12 comments

Bug report

Required System information

  • Node.js version: 14.20.1
  • NPM version: 6.14.17
  • Source Strapi version: 3.6.10
  • Target Strapi version: 4.3.9
  • Source Database: SQL (MariaDB and SQLite)
  • Target Database: SQL (MariaDB and SQLite)
  • Operating system: Ubuntu 20.04
  • Which script are you running: v3-sql-v4-sql

Describe the bug

In some cases, many-to-many relations are not properly migrated and data is missing.

It looks like it has something to do with which attribute is the dominant one, or with the alphabetical order of the referenced content-types, or with the name of the table that stores the relations.

Steps to reproduce the behavior

  1. Run npx create-strapi-app@v3 my-project --quickstart to generate an empty Strapi v3 project
  2. As described in the v3 Quick Start Guide, create the restaurant and categories content-types, but with one difference:
    Instead of adding the many-to-many relation into the category, add it to the restaurant
    image
  3. Create a restaurant and some categories and link them via the relation field
    image image
  4. Notice that the name of the relation table is categories_restaurants__restaurants_categories
    image
  5. Run codemods to migrate code to v4 syntax
  6. Remove package-lock.json, remove node_modules folder, change sqlite3 dependency to latest better-sqlite3 dependency for SQLite + Strapi v4 compatibility (source)
  7. Run npm i
  8. Configure new sqlite database path for Strapi v4 in .env
  9. Run npm run build && npm run develop to start Strapi v4 and let it generate the empty tables, kill process afterwards
  10. Execute the v3-sql-v4-sql script to migrate the database from v3 to v4
  11. Run npm run develop to start Strapi v4
  12. Notice that the many-to-many relations between restaurants and categories are missing:
    image image image

Expected behavior

The restaurant_categories_links table contains the migrated many-to-many-relations.

Additional info

With the "How to reproduce" guide in mind this might look like an artificial issue. But we're currently migrating a v3 project which has been in production for 1.5 years to v4. That project contains some many-to-many relations of all sorts and changing how these relations are defined while ensuring data integrity is something I'm a little afraid of :) By pure chance I found out that some data is missing. I hope there isn't more :(

If you try to reproduce this issue, pay attention to step 2:

When I create the many-to-many relation in the category as described in the Quick Start Guide, the many-to-many relation gets properly migrated. Only when I create it the other way round the migration does not happen.

I suspect it has something to do with either the alphabetical order of the content-type name, or with the dominant property of the attribute.

Although the dominant property would be weird, because the doc mentions that that one is used for NoSQL databases only.

When it's like this the migration will work:

// category.settings.json
{
...
  "attributes": {
    ...
    "restaurants": {
      "collection": "restaurant",
      "via": "categories",
      "dominant": true
    }
  }
}
// restaurant.settings.json
{
  ...
  "attributes": {
    ...
    "categories": {
      "via": "restaurants",
      "collection": "category"
    }
  }
}

But when it's like this the migration will not work:

// category.settings.json
{
...
  "attributes": {
    ...
    "restaurants": {
      "via": "categories",
      "collection": "restaurant"
    }
  }
}
// restaurant.settings.json
{
  ...
  "attributes": {
    ...
    "categories": {
      "collection": "category",
      "via": "restaurants",
      "dominant": true
    }
  }
}

GregorSondermeier avatar Sep 26 '22 15:09 GregorSondermeier