Updates seeds script to be generic, no more errors throw on first run

[cannikin]

If you edit the schema.prisma file and change the table name before running yarn rw prisma migrate dev the first time, you'll get a scary error at the end of your run:

The error is caught, and doesn't stop the migration from running, but looks nasty. Everyone will see this when running through the tutorial as the first thing we do is change the schema.prisma file and then create a migration.

The seed should not contain any actual seed data, just comments about how to use it when the time comes. I've updated the template to be much simpler to start, and includes a link to a new doc I created that goes into more detail about how to use seeds, best practices, etc. The first time you migrate the console message will point you to the file, and the file will point you to the docs.

---

This PR (10739) also needs this to be complete: #10751

[Josh-Walker-GM]

I like this. One comment on the docs and just the linting errors to silence but otherwise looks great to me.

[dthyresson]

Should we take the opportunity to use createMany here now that SQLite supports it with Prisma? prisma/prisma#10710

[cannikin]

So in the docs I talk about the seeds being idempotent, and running the file multiple times won't create new records. Unfortunately with createMany() it'll do just that. :( In the doc I talk about the tradeoffs and a fallback so that you can use createMany() but that you'd want to check first to make sure you're not creating duplicate records.

[cannikin]

Although that makes me realize even THIS code example should use upsert() instead of create() so follow that recommendation!

[dthyresson]

Oh, yes. I would still check.

I just meant not looping and await each create.

if ((await db.user.count()) === 0) {
      await db.user.createMany({ data: users })
    } else {
      console.log('Users already seeded')
    }

      await db.post.createMany({ data: posts })
    } else {
      console.log('Posts already seeded')
    }```

[dthyresson]

I'd leave a check for multiple seed runs and the createMany for initial db seed and db migration resets.

[cannikin]

Ahh, I was going even more granular than that and checking that each individual record was present in the database before creating/updating. All the time when I'm in dev and things are getting updated and deleted all over the place, I can always re-run the seed and be back to a known state with those fixed seeds: I don't want to completely recreate the database from scratch and start over, just get me back to a known minimum amount of data.

I'd leave a check for multiple seed runs and the createMany for initial db seed and db migration resets

How would you know from within the seed script that it's the initial/reset run and not a manual/multiple run?

[cannikin]

Okay you convinced me 😃 How's this?

// Create your database records here! For example, seed some users:
//
// const users = [
//   { name: 'Alice', email: '[email protected] },
//   { name: 'Bob', email: '[email protected] },
// ]
//
// await db.user.createMany({ data: users })

[Tobbe]

I feel like this entire #### Performance section could just have been this 😀 You run seeds like once. Who cares about perf 😆

[cannikin]

haha I agree, although DT does make a good point with createMany(): in my later docs example with the book categories, there are apparently 3,000+ official ones! If you're doing a lot of CI that's one that could probably stand to be as fast as possible, and really no reason to do an upsert() since you won't be manually editing the list and need to restore changed records!

[Tobbe]

LGTM!