19 Replies
looks like the key is
__drizleMigrations
fixing
this one is fixed in 0.19.7
ty
i am getting this on 0.19.7
assume you are using push with tableFilters?
just found this case, will release now in 0.19.8
yea exactly
5 mins
[email protected]
insane
Getting this in
0.19.13
with sqlite:push
*push:sqliteIf you can share what did you change in your schema - will help me a lot
1. Added these two tables:
2. Removed a table named
auth_key
3. In the users
table earlier only the id
was primaryKey, now I have changed it to a composite key of id, organizationId
I was trying push:sqlite against remote turso db database. Then I tried with a fresh local turso db and it worked.
But didn't work with the remote db that already had tables and datagot it, will test this specific case
Sure
Hey @Andrew Sherman were you able to check this?
Not yet, I'll ping you right after I get a chance to look into it
Thanks
hi, has this been fixed? I still get this error
I have just run in to this error too:
v0.20.7
pushing to Turso.
Let me know what additional info will help.
Actually, I figured this out. The issue what that I wasn't pointing to my src/db/schema.ts
file correctly, hence not finding columns
.I'm getting the same issue with the same stack trace using
turso dev
for local development. Version 0.28.5.
@Andrew Sherman if it helps, attached is my debug of the table causing the issue. My change was adding a self referencing column to a table that isn't related to organization_auth
. See 2nd image on migration:Quick discovery. It seems like some of the
__old_push
tables hang around if the push:sqlite
command fails. Once that happens, the undefined 'columns' error pops up.
After manually dropping the table with the sqlite command line client, the push runs and spits back my actual error (foreign key constraint problem on my end), but after that error, another __old_push
table hangs around again. This time, that table had columns, so I actually got a prompt to drop it when running the push again. What made this complicated is those temp tables (I assume due to naming convention) are hidden in drizzle studio. Maybe this helps some of you get unstuck to see the actual error thrown by the driver.
It seems like there needs to be an error catch in drizzle-kit that cleans up the temp tables used if the underlying driver throws.
To clarify, I didn't check the __old_push_organization_auth
table for columns before dropping. I'm just assuming it didn't since the new temp table had columns and I was prompted to drop it during the push