-
-
Notifications
You must be signed in to change notification settings - Fork 39
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
Generate Migration TypeORM #113
Comments
With that being said, i'm not quite sure of the fix to this issue. We should be able to use TypeORM's Generate Migration capabilities considering it is an ORM, and we are already doing this in Core MedusaJS. But our issue here is with importing the Models from Medusa Core into the Extender and still having the same capabilities of generating a migration. |
As discussed, it seams to come from typeorm driver postgres during changes check. So it seams to be linked to typeorm not managing properly the checks |
Adding a few more details per our discussion: This will require updating to At the moment it seems that TypeORM can't distinguish between entities from different repositories which results in the issue that we're seeing. |
I fixed this issue by using .env and add these lines |
@juanzgc did you give it a shot 👆 |
I have not, will attempt this later tonight 👀 |
@aboozaid where did you put your .env file in medusa-store? can you please give me a path? |
@aboozaid I've added the following in the
however, I'm still seeing the same errors. I think it's worth mentioning, I can add the following in
and even though migrations will now always generate, they won't generate correctly. It will attempt to drop indices and foreign keys that shouldn't be dropped. Are you using a I'm not sure if @adrien2p, was able to also give it a shot. But personally, it didn't seem to work on my end. |
I have a monorepo project so I put it in the root
Add these to .env file
when I migrate or create migrations I always use typeorm commands without any ormconfig.js file as I put all configs in .env file and typeorm automatically read from it |
I can confirm this doesn't work on my end. The migration itself will generate but it will be full of constraint removals that are completely incorrect and not what we expect. As expected, there isn't a difference between @aboozaid Would it be possible to see a live demo of you generating migrations? Could you try extending the |
It seems that in Typeorm 3 - this solution might work but we will have to wait until Medusa is migrated to use Typeorm v3: typeorm/typeorm#9122 (comment) |
@adrien2p I don't think the issue is fixed yet, as we are still facing this issue. can you please let it open so that their might be a solution shared by team. 😊 Thanks |
Sorry, i closed it because it is more related to typeorm and did not see any activities 😅 Also, i ve put on hold the migration to typeorm 3 in the core as it was collided a lot with our feature rate 🥹 |
@adrien2p There is an issue when 2 modules override the same entity, i believe the issue in |
Describe the bug
Generating a migration results in errors if the Entity that you are overriding has column types of other Entities (that are imported).
For example:
images
,options
,variants
,profile
,collection
,type
,tags
,sales_channel
]Whereas User doesn't face this error because there are no column types of other imported entities.
It seems that for whatever reason, when generating the migration with extended Entities, typeorm has difficulty with nested imports.
@medusajs/medusa/dist/models/product.d.ts
:@medusajs/medusa/dist/models/user.d.ts
:To Reproduce
Steps to reproduce the behavior:
ormconfig.json
package.json
:typeorm
:Entity metadata for Product#images was not found
. However, if you add anexport
to the Product Entity extender you won't see the same error. The error will now beEntity metadata for Product#options was not found
.The line changed was:
export { Image } from '@medusajs/medusa/dist/models';
Don't forget to
yarn build
before re-attempting to generate the migration.You can continue adding all the remaining exports until the migration is generated, however, it will also generate a faulty migration because it will include multiple FKs and Indexes that it attempts to delete. I believe if we could somehow move all Entities into one file and export from one file (at build time), we would no longer see these migration errors.
You can also try this with an easier Entity such as
Store
which has less Columns that are referenced by other EntitiesExpected behavior
Generate a migration without having to go through these hacks to get one generated. Generating migrations in the Medusa Core doesn't have these issues.
Screenshots
If applicable, add screenshots to help explain your problem.
Package version:
Additional context
Similar Issue
The text was updated successfully, but these errors were encountered: