fixed typos in waspc/design-docs/db-seeding.org and waspc/design-docs/server-setup.md (#1499)

This commit is contained in:
Parikshit Adhikari 2023-10-17 21:21:29 +05:45 committed by GitHub
parent 15d7a0cae1
commit bbfbd77230
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 2 additions and 2 deletions

View File

@ -13,7 +13,7 @@ I might want to have multiple such states, each of them named.
I imagine this would actually be easier to do by doing snapshots of db then having seeding script, so I don't think this is what Prisma is targeting with their =seed=.
So I probably went here a bit into a different use case -> still interesting though.
Actuall, I read a bit more and seeding script is also valid way to do this.
Actually, I read a bit more and seeding script is also valid way to do this.
As for snapshots -> I guess this would come down to doing postgre exports and then saving those in git and loading them.
I saw this being called "SQL backup file" somewhere.

View File

@ -38,7 +38,7 @@ The solution that people suggested was an async function that returns an object
### Basic
- Dev can specify, through wasp language, a JS function that will be executed on server start.
Such function would be async, take no arguments, and return an object that would be avaialable in operations (through `context`).
Such function would be async, take no arguments, and return an object that would be available in operations (through `context`).
### Advanced
- Instead of returning an object that will be added to `context`, function could return a function that modifies the `context`.