ABP Suite 10.4.0 regeneration silently renames many-to-many join entities, producing a data-destroying migration #10860

7 Answer(s)

• 

  0

  AI-Bot created one month ago

  Support Team ABP Agent

  • Q1 (intentional? which version?): I can’t verify (with the available indexed docs/code context) when or why ABP Suite changed the naming convention for many-to-many join artifacts (e.g., WorkerCompany → WorkerCompanies, AddCompany → AddToCompanies, AppWorkerCompany → AppWorkerCompanies). The searchable sources I have do not include Suite changelogs or generator code that would let me definitively pinpoint the first version that introduced this behavior.

  • Q2 (where documented?): I can’t find any verified ABP documentation that calls out a breaking change about regeneration producing different join-entity/method/table names between Suite versions, nor any guidance that warns about EF Core migrations potentially being scaffolded as Drop/Create instead of Rename in this scenario. The only directly relevant official page I can verify is the general “creating many-to-many relationship” document, which describes the feature but does not mention naming stability across Suite versions or regeneration pitfalls.

  • Q3 (recommended safe path on 10.4.0): The safe, practical approach (to avoid data loss) is:

    1. Do not apply the auto-scaffolded migration as-is if it contains DropTable / CreateTable for association tables that already have production data.
    2. Manually edit the migration to use a rename operation instead of drop/create or otherwise preserve/copy data.
       • For EF Core, that typically means replacing the drop/create with migrationBuilder.RenameTable(...) (and RenameIndex if needed), or implementing a data-move approach (create new table, copy data with SQL, then drop old).
    3. Treat regeneration as a potentially breaking operation and review:
       • generated entity APIs (method names),
       • DbContext table mappings,
       • and the resulting migration script before it ever reaches production.
    4. Mitigate test GUID churn: if Suite regenerates test seed contributors with new GUIDs, you’ll need to restore the previous constants/values (or refactor tests to avoid hard-coded GUID cross-references) before running tests. I can’t verify an official “switch” to keep GUIDs stable.

    I cannot verify any supported Suite option in 10.4.0 that forces the generator to keep the old singular join naming convention for existing entities.

  • Q4 (should Suite delete obsolete join entity files?): I can’t verify an official guarantee that Suite removes previously generated/now-obsolete join entity classes during regeneration. Based on what you observed (old join entity classes left behind), you should assume it may not clean them up, and you should manually delete/merge them as part of your regeneration review (after confirming nothing references them).

  References (validated)

  • https://abp.io/docs/10.4/suite/creating-many-to-many-relationship
  • https://abp.io/docs/latest/suite/creating-many-to-many-relationship
  • https://abp.io/docs/10.3/release-info/migration-guides/abp-10-3

  ---

  This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  pajokit created one month ago

  Team please

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  maliming created one month ago

  Support Team Fullstack Developer

  Hi,

  The naming change was introduced in Suite 10.2 to support multiple many-to-many relations to the same entity. Existing entities generated before 10.2 are not handled safely during regeneration.

  For now, do not apply the generated migration with DropTable("AppWorkerCompany") and CreateTable("AppWorkerCompanies"). Keep the generated AddColumn operation for your new property, but replace the join-table drop/create operations with a safe rename:

  migrationBuilder.DropForeignKey(
      name: "FK_AppWorkerCompany_AppCompanies_CompanyId",
      table: "AppWorkerCompany");
  
  migrationBuilder.DropForeignKey(
      name: "FK_AppWorkerCompany_AppWorkers_WorkerId",
      table: "AppWorkerCompany");
  
  migrationBuilder.DropPrimaryKey(
      name: "PK_AppWorkerCompany",
      table: "AppWorkerCompany");
  
  migrationBuilder.RenameTable(
      name: "AppWorkerCompany",
      newName: "AppWorkerCompanies");
  
  migrationBuilder.RenameIndex(
      name: "IX_AppWorkerCompany_CompanyId",
      table: "AppWorkerCompanies",
      newName: "IX_AppWorkerCompanies_CompanyId");
  
  migrationBuilder.RenameIndex(
      name: "IX_AppWorkerCompany_WorkerId_CompanyId",
      table: "AppWorkerCompanies",
      newName: "IX_AppWorkerCompanies_WorkerId_CompanyId");
  
  migrationBuilder.AddPrimaryKey(
      name: "PK_AppWorkerCompanies",
      table: "AppWorkerCompanies",
      columns: new[] { "WorkerId", "CompanyId" });
  
  migrationBuilder.AddForeignKey(
      name: "FK_AppWorkerCompanies_AppCompanies_CompanyId",
      table: "AppWorkerCompanies",
      column: "CompanyId",
      principalTable: "AppCompanies",
      principalColumn: "Id",
      onDelete: ReferentialAction.Cascade);
  
  migrationBuilder.AddForeignKey(
      name: "FK_AppWorkerCompanies_AppWorkers_WorkerId",
      table: "AppWorkerCompanies",
      column: "WorkerId",
      principalTable: "AppWorkers",
      principalColumn: "Id",
      onDelete: ReferentialAction.Cascade);
  

  Use the same pattern for AppCompanyRepresentativeCompany → AppCompanyRepresentativeCompanies, and reverse these operations in Down.

  After regeneration, update your hand-written calls to the new method names and remove the old join entity files after checking that they contain no custom code. For the generated test data, restore the previous Guid.Parse(...) values in the regenerated seed contributor and its regenerated tests. Suite 10.5 and later generate stable test GUIDs.

  Suite 10.4 has no option to keep the old naming convention. We will add compatibility handling for entities generated with the legacy naming convention.

  Thanks

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  pajokit created one month ago

  Hi,

  Thanks. And where is this change documented as we were not able to find it? We tried to upgrade to latest ABP Suite btw but were told as it loaded the Solution that we needed to downgrade. This seem like a breaking change with no way out of besided stop using ABP Suite and change code by hand with zero documentation besides the answer above?

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  maliming created one month ago

  Support Team Fullstack Developer

  Hi,

  The Suite naming change was not documented in the 10.2 migration guide. That was our oversight.

  Studio switches Suite to the ABP version used by the solution; that is the downgrade prompt you encountered. Suite 10.7 therefore cannot be used to regenerate a solution that remains on 10.4. The compatibility fix has been merged into 10.7 and will ship in a 10.7 package.

  For your current 10.4 solution, the safest temporary path is to keep the legacy relationship names and database tables. This is a simpler alternative to the rename migration I sent earlier. If you have already replaced the drop/create operations with a safe rename and applied it successfully, you can keep that result. Otherwise:

  1. Remove the migration or migrations created by these regenerations, newest first, using EF Core migrations remove. If one was applied only to a development database, roll that database back to the preceding migration first, then remove it. Do not roll back a production database containing data this way.
  2. Keep the code generated for the new properties, but restore the relationship-related changes from source control: WorkerCompanies back to WorkerCompany, AddToCompanies / RemoveFromCompanies back to AddCompany / RemoveCompany, and the previous DbContext mappings. Do the same for CompanyRepresentativeCompany.
  3. Delete the new plural join entity files generated by Suite.
  4. Restore the previous GUID values in every regenerated test seed contributor and test file.
  5. Build the solution, then create the migration again. It must contain only the AddColumn operations for the new properties and no operations for AppWorkerCompany or AppCompanyRepresentativeCompany. Do not apply it if either join table appears in the migration.

  Until then, with Suite 10.4, avoid regenerating any entity that was created before this naming change and has a many-to-many relation. Once a 10.7 package containing the compatibility fix is available, upgrade the solution and Suite together.

  Thanks

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  pajokit created one month ago

  Hi,

  This seems like a lot of work for something that used to work and came as a total surprise to us as it was a big breaking change that was not documented anywhere.

  What is the path forward here to actually use ABP and ABP Suite as intended and we want to avoid tedious handcrafting with every change?

  Thanks.

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  maliming created one month ago

  Support Team Fullstack Developer

  Hi,

  You can stay on 10.4. This requires one controlled conversion for Worker and CompanyRepresentative, not manual relationship changes after every future regeneration of these entities.

  Do not apply the current migration. Please send the generated migration and Git diff, or invite https://github.com/maliming to a private repository. I will prepare and check the exact patch that:

  • replaces the join-table drop/create operations with data-preserving renames;
  • removes the obsolete join entity files and updates the affected method calls;
  • aligns the affected test seed GUID references.

  After this one-time conversion, Suite 10.4 will keep the new naming when these entities are regenerated again. While using Suite 10.4, turn off Create tests when regenerating existing entities so their test GUIDs are not generated again. Newly created entities already use the current naming.

  Thanks

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel