Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: convert MikroORM entities to DML entities #10043

Merged
merged 106 commits into from
Nov 26, 2024

Conversation

thetutlage
Copy link
Contributor

@thetutlage thetutlage commented Nov 12, 2024

Fixes FRMW-2790, FRMW-2777, FRMW-2798, FRMW-2800

DML Changelog

  • Fix: Mark foreign key as null when the relationship is marked a nullable.
  • Fix: Do not set isForeignKey: true on the generate MikroORM property for the belongsTo relationship. However, the index in the database is still created. This is done to match the behaviour of relationships defined via MikroORM.
  • Fix: manyToMany relationship to infer owner side of the relationship without relying on the order in which models are imported. Earlier, the first imported model was marked as the owner. Could result in a breaking change especially in regards to joinKey and inverseJoinKey columns. But the same can be fixed by explicitly defining these properties.
const isOwner =
    !!joinColumn ||
    !!inverseJoinColumn ||
    !!relationship.options.pivotTable ||
    /**
     * We can't infer it from the current entity so lets
     * look at the otherside configuration as well to make a choice
     */
    (!otherSideRelationOptions.pivotTable &&
      !otherSideRelationOptions.joinColumn &&
      !otherSideRelationOptions.inverseJoinColumn &&
      !MANY_TO_MANY_TRACKED_RELATIONS[
        `${relatedModelName}.${otherSideRelationshipProperty}`
      ])

// This means that a relation is infered as owner if there is one of the following options set on the relation
// - joinColumn
// - inverseJoinColumn
// - pivotTable
// if none are present, then we check if the otherside has none of those options as well and if it has not be loaded yet, 
// in that case the current entity (first to be loaded) can be owner. If the other side has any of those options then it will be
// inferred as owner when it will get loaded later
  • Fix: Set inversedBy: true on the owner side of the manyToMany relationship.
  • fix: manyToMany pivot table name generation have been fixed. Meaning that it can be breaking changes in the scenario where no pivotTable were provided. In order to fix the breaking change if needed, the user can provide the pivotTable configuration with the existing name of the pivot table. (previously was using the models name in alpha order and pluralized last name, now it is using the table name from the model in alpha order with last one pluralized)
// If this create a breaking change for you then you can specify the `pivotTable` property configuration on the many to many with the current table name

// Something along those lines
const user = model.define('User', () => {
  addresses: model.manyToMany(() => Address, { pivotTable: 'address_users' })
})
  • fix: joinerConfigBuilder now merges the auto-generated primary keys with the one provided in the custom configuration if any
  • fix: joinerConfigBuilder now merges the auto-generated linkable with the one infered from the custom linkable keys provided if any
  • improvement: Always auto generate index for deleted_at where is null
  • fix: category rank ordering was broken (see)

Copy link

vercel bot commented Nov 12, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
api-reference 🔄 Building (Inspect) Visit Preview 💬 Add feedback Nov 26, 2024 0:11am
medusa-dashboard 🛑 Canceled (Inspect) Nov 26, 2024 0:11am
5 Skipped Deployments
Name Status Preview Comments Updated (UTC)
api-reference-v2 ⬜️ Ignored (Inspect) Visit Preview Nov 26, 2024 0:11am
docs-ui ⬜️ Ignored (Inspect) Visit Preview Nov 26, 2024 0:11am
docs-v2 ⬜️ Ignored (Inspect) Visit Preview Nov 26, 2024 0:11am
medusa-docs ⬜️ Ignored (Inspect) Visit Preview Nov 26, 2024 0:11am
resources-docs ⬜️ Ignored (Inspect) Visit Preview Nov 26, 2024 0:11am

Copy link

changeset-bot bot commented Nov 12, 2024

⚠️ No Changeset found

Latest commit: 95c3559

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@@ -20,12 +20,15 @@ export class ProductCategoryRepository extends DALUtils.MikroOrmBaseTreeReposito
familyOptions: ProductCategoryTransformOptions = {}
) {
const findOptions_ = { ...findOptions }
findOptions_.options ??= {
orderBy: { rank: "ASC" },
findOptions_.options.orderBy = {
Copy link
Member

@adrien2p adrien2p Nov 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note: in the tests, the fields where provided and hence the options always populated, meaning that the order was never applied. By some random luck from god, the order remain the same for a long time, but the truth is that without any ordering we cant guarantee the order of the retrieved data. Now we always apply both rank and id, because rank only would also randomize all categories with the same rand and hence not enforce any ordering among each rank value. Now all categories are always ordered and the order remain constant.

further more, the rank was never selected, meaning that when we include ancerstors or descendant, the sortCategoriesByRank cant work since it is based on the property rank which was never deleted. I am really unsure how it worked so far except luck :)

cc @olivermrbl maybe you have an idea?

@olivermrbl
Copy link
Contributor

Fix: manyToMany relationship to infer owner side of the relationship without relying on the order in which models are imported

Maybe this will be clear from the code, but can you describe how we are inferring this now?

@adrien2p
Copy link
Member

adrien2p commented Nov 25, 2024

Fix: manyToMany relationship to infer owner side of the relationship without relying on the order in which models are imported

Maybe this will be clear from the code, but can you describe how we are inferring this now?

sure, do you want it in the description or in a comment?

nvm: I ve updated the description

Copy link
Contributor

@olivermrbl olivermrbl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really nice work guys, love how simple the data model definitions are with the DML 💪

Copy link
Contributor

@olivermrbl olivermrbl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall this LGTM, nice work

Can we add more descriptive guides for how you can avoid the breaking changes by setting the configurations explicitly? Would like to include these in the upgrade guide.

@adrien2p
Copy link
Member

Overall this LGTM, nice work

Can we add more descriptive guides for how you can avoid the breaking changes by setting the configurations explicitly? Would like to include these in the upgrade guide.

I ve added a mention and an example

@adrien2p
Copy link
Member

@olivermrbl lets wait for the pipeline but I believe we should be good now

@thetutlage
Copy link
Contributor Author

/snapshot-this

Copy link
Contributor

🚀 A snapshot release has been made for this PR

Test the snapshots by updating your package.json with the newly published versions:

yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]
yarn add @medusajs/[email protected]

Latest commit: da536ab

@thetutlage thetutlage merged commit 9f20481 into develop Nov 26, 2024
23 checks passed
@riqwan riqwan deleted the feat/product-module-dml-migration branch November 26, 2024 14:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants