cli
cli copied to clipboard
No `seed.sql` after `supabase init`
Bug report
Describe the bug
There is no supabase/seed.sql
after using supabase init
as it is mentioned in the documentation.
To Reproduce
Just follow the documentation on https://supabase.com/docs/guides/local-development
.
Expected behavior
After using supabase init
there should be a file called seed.sql
.
System information
- OS: macOS
- Version of supabase cli: 0.26.1
Additional context
I created the seed.sql
file myself and could follow the documentation without any additional error.
So it is just the part of creating the file by default after supabase init
Another comment here:
If the seed.sql
file contains too many lines, the seeding procedure will fail silently.
It makes it hard to understand why the seeding does not work.
Not sure how many lines is too many, but this happened to me because I was generating the seed.sql
file from a pg_dump
of an existing test database.
It would be good to have some kind of console output for supabase db reset
on failure to help debugging.
@vejja This explains a lot. I've been struggling to get my seed.sql
file to work. It performs a bunch of SQL insert commands to populate the database with data from my old hobby project so it's easier to check that my queries returns the same values as before. Somehow it has been failing for me as well and I've needed to manually run the queries after running the migration.
:tada: This issue has been resolved in version 1.10.2 :tada:
The release is available on:
Your semantic-release bot :package::rocket:
The problem @vejja is describing is still happening to me. I am on version 1.11.7 of the cli.
My seed.sql
has roughly 270 insert statements but I get this error:
Seeding data supabase/seed.sql...
Error: ERROR: relation "challenges" does not exist (SQLSTATE 42P01)
challenges
is one of my table names.
When I insert all insert commands in the studio and execute the sql there, seeding works fine.
If I remove my seed.sql
file and apply migration that also works fine.
Hi @thomasmol, is your challenges
table created in seed.sql
or a separate migration file? DDL statements like create table are not designed to be used in seed.sql
.
To create a new migration, you can use supabase migration new <name_of_file>
command. It creates an empty file where you can add create table statements.
If you are sure that the table is created in its own migration, you might also want to prefix references to challenges
table with its schema, for eg. "public"."challenges"
. This helps to avoid ambiguity resolving tables with default search path.
Let me know if either solution works for you.
Quick note to anyone who stumbles on this:
I ran across this today, not realizing I was running an old version of the cli. Make sure you're version is up to date if you run into this!
https://supabase.com/docs/guides/cli#updates
previous versions of the supabase cli would automatically run the seed.sq on supabase start. I just put a bunch of insert statements and restarted my containers but none of this data was inserted into the contact_us table. My tables do have RLS. Does the seed sql only insert into tables without RLS?
`-- seed data for the public.contact_us table INSERT INTO "public"."contact_us" ("name", "email", "phone", "subject", "message") VALUES ('John Doe', '[email protected]', '123-456-7890', 'Inquiry about product', 'Can you provide more details about your product?');
INSERT INTO "public"."contact_us" ("name", "email", "phone", "subject", "message") VALUES ('Jane Smith', '[email protected]', '234-567-8901', 'Feedback', 'Your service has been very helpful. Thank you!');
INSERT INTO "public"."contact_us" ("name", "email", "phone", "subject", "message") VALUES ('Bob Martin', '[email protected]', '345-678-9012', 'Complaint', 'I am having an issue with my order. Please assist.'); `
A recent change we did was to auto backup db volumes on supabase stop. This means when you run supabase start, your local development data will resume from the last time it stopped.
One way to seed again is by supabase db reset
. Alternatively you can also drop the backup volume by running supabase stop --no-backup
.
The following fixed a long-running issue I had with supabase seeds:
If you are sure that the table is created in its own migration, you might also want to prefix references to
challenges
table with its schema, for eg."public"."challenges"
. This helps to avoid ambiguity resolving tables with default search path.
I did add the tables in a migration but had multiple errors where the table was not found when inserting data in seed.sql. Adding the schema resolved it, thank you so much @sweatybridge!