**What**
DML class name and mikro orm entity name are different, it was ok and the idea was to accept that and do the transformation when needed. But since class name are usually upper case first we decided to re integrate that convention in the DML class name as well to simplify consumption of the dml name without having to worry about the normal case
RESOLVES FRMW-2813
**What**
Extract what we have done in the order module DML migration.
This includes all the changes we discussed around default value and nullable management
From now on, when the default is being set through the DML on a property, no default initializer will be created, this means that when a mikro orm class is being instantiated, no default will be applied at instantiation time. This fixes the issue when retrieving data and not selecting fields that have a default. The default initializer was taking the relay making you think the data was present except that it was the value of the default initializer. From now on, the default value is applied as follows
- db column default
- before flush
- on persist
The same applies for nullable properties/columns
Co-authored-by: Harminder Virk <1706381+thetutlage@users.noreply.github.com>
* feat: convert MikroORM entities to DML entities
* feat: wip on repository changes
* continue repositories and types rework
* fix order repository usage
* continue to update product category repository
* Add foreign key as part of the inferred DML type
* ../../core/types/src/dml/index.ts
* ../../core/types/src/dml/index.ts
* fix: relationships mapping
* handle nullable foreign keys types
* handle nullable foreign keys types
* handle nullable foreign keys types
* continue to update product category repository
* fix all product category repositories issues
* fix product category service types
* fix product module service types
* fix product module service types
* fix repository template type
* refactor: use a singleton DMLToMikroORM factory instance
Since the MikroORM MetadataStorage is global, we will also have to turn DML
to MikroORM entities conversion use a global bucket as well
* refactor: update product module to use DML in tests
* wip: tests
* WIP product linkable fixes
* continue type fixing and start test fixing
* test: fix more tests
* fix repository
* fix pivot table computaion + fix mikro orm repository
* fix many to many management and configuration
* fix many to many management and configuration
* fix many to many management and configuration
* update product tag relation configuration
* Introduce experimental dml hooks to fix some issues with categories
* more fixes
* fix product tests
* add missing id prefixes
* fix product category handle management
* test: fix more failing tests
* test: make it all green
* test: fix breaking tests
* fix: build issues
* fix: build issues
* fix: more breaking tests
* refactor: fix issues after merge
* refactor: fix issues after merge
* refactor: surpress types error
* test: fix DML failing tests
* improve many to many inference + tests
* Wip fix columns from product entity
* remove product model before create hook and manage handle validation and transformation at the service level
* test: fix breaking unit tests
* fix: product module service to not update handle on product update
* fix define link and joiner config
* test: fix joiner config test
* test: fix joiner config test
* fix joiner config primary keys
* Fix joiner config builder
* Fix joiner config builder
* test: remove only modifier from test
* refactor: remove hooks usage from product collection
* refactor: remove hooks usage from product-option
* refactor: remove hooks usage for computing category handle
* refactor: remove hooks usage from productCategory model
* refactor: remove hooks from DML
* refactor: remove cruft
* cleanup
* re add foerign key indexes
* chore: remove unused types
* refactor: cleanup
* migration and models configuration adjustments
* cleanup
* fix random ordering
* fix
* test: fix product-category tests
* test: update breaking DML tests
* test: array assertion to not care about ordering
* fix: temporarily apply id ordering for products
* fix ordering
* fix ordering remove logs
---------
Co-authored-by: adrien2p <adrien.deperetti@gmail.com>
Co-authored-by: Oli Juhl <59018053+olivermrbl@users.noreply.github.com>
* migration
* fix snapshot
* primarykey
* init work on dnd
* progress
* dnd
* undo changes
* undo changes
* undo changes
* undo changes
* fix firefox issue
* lint
* lint
* lint
* add changeset
* undo changes to product module
* set activator node
* init work on service layer
* alternative
* switch to OneToMany
* add tests
* progress
* update migration
* update approach and remove all references to images in product.ts tests
* handle delete images on empty array
* fix config and order type
* update changeset
* rm flag
* export type and fix type in test
* fix type
---------
Co-authored-by: Oli Juhl <59018053+olivermrbl@users.noreply.github.com>
What:
- `Dirent` class from `NodeJS` has different properties in different versions, causing issues in our loaders.
- Util `readDirRecursive` was introduced, avoiding old node versions to break
FIXES: https://github.com/medusajs/medusa/issues/8419
**What**
- add request order transfer workflow
- add admin endpoint for transferring an order to a customer
- accept order transfer storefront endpoint
- accept transfer workflow
- changes in the order module to introduce new change and action types
---
**Note**
- we return 400 instead 409 currently if there is already an active order edit, I will revisit this in a followup
- endpoint for requesting order transfer from the storefront will be added in a separate PR
---
RESOLVES CMRC-701
RESOLVES CMRC-703
RESOLVES CMRC-704
RESOLVES CMRC-705
Initially I thought that we will have to add special checks to allow relationships referencing itself. However, it turned out that not to be the case. Instead, it had more to do with how self relationships are defined in Mikro ORM.
In case of `belongsTo` relationship we have to define the other side as well either as a `hasMany` or `hasOne`. For example:
**❌ The following code will fail, because no children are defined for the parent**
```ts
const user = model.define("user", {
id: model.number(),
username: model.text(),
parent: model.belongsTo(() => user)
})
```
**✅ Addition of children relationship will make things work**
```ts
const user = model.define("user", {
id: model.number(),
username: model.text(),
parent: model.belongsTo(() => user, { mappedBy: "children" }),
children: model.hasMany(() => user, { mappedBy: "parent" }),
})
```
We can see the similar setup here with our `ProductCategory` MikroORM entity. https://github.com/medusajs/medusa/blob/develop/packages/modules/product/src/models/product-category.ts#L87-L94
@adrien2p Correct me if I am wrong. But I have added the tests for now so that we know the behavior of self relationships
**What**
Currently, when setting a `belongsTo` relationship on the DML with the otherside being `hasMany` it result in a wrongly generated gql output making the belongs to being a collection of the relation instead of the relation directly. This pr fixes this issue
**What**
- Fix product category repository missing context passed to down level methods
- Ensure the base repository when getting the active manager returns a fresh one if possible instead of the global one in order to prevent shared entity map by mistake
* chore: Update modules providers configuration with 'identifier' and 'PROVIDER'
* update check
* fix tests
* type
* normalize auth provider
* emailpass
* providers
---------
Co-authored-by: Carlos R. L. Rodrigues <rodrigolr@gmail.com>
Co-authored-by: Carlos R. L. Rodrigues <37986729+carlos-r-l-rodrigues@users.noreply.github.com>
What:
* removes resouces type "shared" or "isolated" from internal modules.
* modules can have an isolated database connection by providing a database config as part of their options on `medusa-config`
CLOSES: FRMW-2593
**Breaking changes**
The `outDir` has been deprecated and wont be used anymore, instead all the path are computed internally following these rules
- if admin is not `disabled` and the `build` command is run without the `--admin-only` flag, then the admin output dir will be `.medusa/server/public/admin` and it will be served from that same location from the medusa instance.
- if admin is not `disabled` and the `build` command is run with the `--admin-only` flag, then the admin output dir will be `.medusa/admin` with the purpose of deploying the admin separately. ⚠️ (expect to receive a warning log)
- if the admin is `disabled` and the `build` command is run with the `--admin-only` flag, then fallback to rule number 2
| admin enabled | medusa build --admin-only | output dir |
|---|---|---|
| true | true | `.medusa/admin` ⚠️ (expect to receive a warning log) |
| true | false | `.medusa/server/public/admin` |
| false | true | `.medusa/admin` |
| false | false | none |
```diff
// medusa-config.ts
{
// ...
admin: {
- outDir: 'some/path'
}
}
```
cc @kasperkristensen @sradevski @olivermrbl
**What**
When resolving the modules through an array, if the module does not have a joiner config to rely on (not `queryable`, not using the `Module` util), then the key should be provided to register the module in the container. Eventually, the module author should provide that key to be used.
The only exception is for the medusa modules where we have a map that allows us to resolve that key automatically from the path of the resolve value
**What**
The module service name case has changed and the hash generation was performed on the non lower cased version of it while after the hash generation everything is based on the lower case version of the generated table name form the service names leading to different hash computation. This pr update the link migration table to adjust the to/from module value with its new value as well as generating the hash from the lower case version of the computed table name
Co-authored-by: Carlos R. L. Rodrigues <37986729+carlos-r-l-rodrigues@users.noreply.github.com>
