Skip to content
This repository was archived by the owner on Oct 7, 2024. It is now read-only.
This repository was archived by the owner on Oct 7, 2024. It is now read-only.

Data of relations in some cases not migrated #70

@GregorSondermeier

Description

@GregorSondermeier

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
    }
  }
}

Metadata

Metadata

Labels

issue: bugIssue reporting a bugseverity: mediumIf it breaks the basic use of the product but can be worked aroundstatus: pending reproductionWaiting for free time to reproduce the issue, or more information

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions