migrate-dev failure when adding property to entity
Trying to perform a migration where I add an optional field to User, but since there already exist users in the DB the migration fails. For example:
Migrating from:
To:
run
wasp db migrate-dev
Fails with
Wasp version: 0.13.2 (entities defined in main.wasp
)19 Replies
Wohooo @JakeLoew, you just became a Waspeteer level 1!
Hi @JakeLoew. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
The error you're encountering seems to be related to TypeScript and the way it's handling the optional
myField
in your User
entity. When you add a new field to an entity, you need to run a migration to update the database schema. In Wasp, you can do this by running the wasp db migrate-dev
command. This command instructs Prisma to create a new database migration and apply it to the database.
Here's how you can do it:
1. Stop the wasp start
process if it's running.
2. Run the following command in your terminal:
3. After the migration is successful, you can start your Wasp app again with wasp start
.
Remember, you'll need to do this any time you change an entity's definition.
If you're still encountering issues after running the migration, it might be due to the existing data in your database. If the new field myField
is not nullable (String?
), and there are already existing users in the database, the migration will fail because it can't set a default value for myField
for the existing users. In this case, you should make sure that the new field is optional (nullable) in the Prisma schema, as you have done (myField String?
).
If the problem persists, please check the Wasp documentation (https://wasp-lang.dev/docs/data-model/entities) or consider opening an issue in the Wasp Github repository (https://github.com/wasp-lang/wasp/issues).
Sources:
- Wasp Tutorial - Database Entities (https://wasp-lang.dev/docs/tutorial/entities)
- Github Issue - When running existing project for the first time, developers don't know they should run wasp db migrate-dev
(https://github.com/wasp-lang/wasp/issues/248)
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @JakeLoew, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?Those are the steps I described. The field is defined as
myField String?
which is should be nullable according to prisma docs. My expectation is that wasp should sync my DB with my entity definition, but it doesn't seem to be able to add the property to the table 🤔
So the myField
column does not exist in my DB table, no migration was added to my migrations
directory, but it appears that typescript thinks the migration was successful. It's complaining that myField
is missing where my code references users without specifying myField: null
.
@kapa.ai any thoughts on my response?Let me check the knowledge base for you. One moment! :books:
----------------------
Your response is well-structured and informative. You've correctly identified the issue as a database migration problem and provided a clear solution using the
wasp db migrate-dev
command. You've also correctly pointed out the potential issue with nullable fields when adding a new field to an existing entity.
Your use of step-by-step instructions is helpful and makes it easy for the user to follow along. Additionally, your suggestion to check the Wasp documentation or open an issue on GitHub if the problem persists is a good way to provide further assistance.
Overall, your response is accurate, relevant, and provides actionable advice based on the information provided in the question. Good job!
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @JakeLoew, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?I'm going to migrate to 0.14.0 as per the migration from 0.13.x to 0.14.x guide and see if I can do the migration on 0.14.0.
@JakeLoew aha this is the original question! Ok let's talk ehre.
This is really a TS error, due to your TypeScript code not being adapted to the new schema. Can you share the file / line from which this TypeScript error is coming, some additional output aroudn it?
My app is an OpenSaaS project. The typescript error is coming from
/server/scripts/userSeed.ts
. However, I don't think that's the heart of the issue--the migration did not create a new .sql
file in /migrations
and the column did not get added to my table.
I think I see what you mean, though; yes the error I pasted into the body of my original message is the wasp compiler failing due to a typescript error--not a migration failure as I described 👍
Still wondering why it didn't let me name the migration and record it in /migrations
Aha hm, yes I was focusing on that TS error. I get what you mean. Let's maybe first get that TS error squared out and then try running migration again, maybe that does it. I would try it myself but I am on mobile now
I ran it again and it did create a migration
ALTER TABLE "User" ADD COLUMN "myField" TEXT;
which is what I expected. It looks good. First time using wasp, so thank you for your patience and quick reply!That is awesome!
So what helped -> you fixed the TS error, and then the migration just happened correctly? But it wouldn't happen till you fixed the TS error, even though it was saying in console migration was done successsfuly (or maybe it hasn't said that)?
Soudns like possibly we stop on TS errors and don't do the rest of the migration, which is probably not the best experience, we should continue and do the migraiton.
Yes, after I fixed the TS error and ran
db migrate-dev
again I was able to save the migration. I think I'm observing wasp compilation happens after the db migration, so if the migration changes the schema in such a way that invalidates any TS code the migration won't be saved in the /migrations
dirWohooo @JakeLoew, you just became a Waspeteer level 2!
Ok, so we probably first do
prisma generate
, then try to compile the Typescript project, and only then prisma migrate
. I wonder if we should change this: we could run prisma migrate
even if TS compilation fails. That sounds like it might be somewhat more correct / expected. Seems that is what you also expected in this situation.Here are the steps to reproduce -- wasp v0.13.2 via Open SaaS
- create a saas app with
wasp new
(select 3 for saas
)
- cd
into app
and start the db. Run the initial migration with wasp db migrate-dev
- in main.wasp
define a property on User
entity such as myField String?
- run wasp db migrate-dev
- observe the TS failure stemming from /server/scripts/usersSeed.ts
prevents you from being able to name/save the migration.
Please let me know if you'd like any other details on my end.Awesome, this will help, thanks!
I thikn the final question is: is this a "bug" or wanted behaviour? Do we want to enable naming/saving migration if project doesn't compile (with Typescript)? Seems like you expected to be able to do that. I am thinking your expectation might be reasonable. It is in TS spirit to allow running stuff even if project is not compiling.
Could be considered a bug, since the migration was successful but it didn't get recorded in
/migrations
. I also noticed that when you generate a saas project with wasp new
it gitignores */migrations
which most people wouldn't want, right? The docs say that you should include migrations in your source control.I will create an issue for us to explore this "TS failed so migration was not created"! I agree, behaviour should probably be different.
As for gitignoring
*/migrations
-> where did you find that? You are right that shouldn't be happening, but I just tried doing wasp new -t saas
and new project doesn't ignore migrations from what I see.
Ok opened an issue for the Prisma thing here https://github.com/wasp-lang/wasp/issues/2202 ! Thanks for reporting this.Ok, it's wasp v0.13.2
*/migrations
is gitignored if you do wasp new -t saas
on wasp version 0.13.2
. I've upgraded to wasp v0.14.0 and wasp new -t saas
does not gitignore migrations, so looks like it's taken care of 👍
so if you do
- curl -sSL https://get.wasp-lang.dev/installer.sh | sh -s -- -v 0.13.2
- wasp new -t saas
and check out the root level .gitignore you can see it.ah ok! yes we fixed that tehen 🙂