Quick Start
Assumptions
This guide will take you through the process of using @snaplet/seed
to create realistic, production-like data.
Prerequisites
You already followed the installation guide and have @snaplet/seed
available locally.
Our first Seed script
Given this PostgreSQL database schema of a blog application:
Let's see how @snaplet/seed
gives a programmatic interface to describe seeding requirements.
We need to apply this schema to a new PostgreSQL database.
Once done, we can edit the configuration file seed.config.ts
to point to the database. We assume we already have our database client library postgres
installed.
We can now generate our @snaplet/seed
assets by running:
It's time to write our first seed script!
Let's start with a bare minimum seed script.
For our example blog application, let's assume we need the following data:
- A post titled "Hello World!"
- A post author, with an email address that ends with "acme.org."
- Three comments on the post.
It's worth noting what we're not explicitly defining - that each comment needs to have a separate, unique author, for instance. We're assuming that @snaplet/seed
will fill in the blanks based on the schema and seed realistic data as needed.
seed
in the code above exposes all the models (i.e. the database tables, or the entities in our blog application - in this case "user" and "post") as functions.
These functions return what we call a plan. When describing a plan, we always start from a "root" model - a model where we would start describing how to seed seed data, along with data for its related models (more on this soon).
Here we start from the posts
models. await
ing a plan will execute it.
We can directly define the values of our model.
We can also define the values of our model's relationships.
Here we define the author of the post represented by the author
field.
Next, we also define the comments of the post represented by the comments
field.
As we need more than one comment, we can use the x
function which will create a list of similar comments.
We can read it as "comments times 3".
Finally:
- We'll add a
dryRun
option when creatingSeedClient
- in dry run mode, we'll log the sql statements to the console instead of altering the database. - and a
$resetDatabase()
call - this will clear the database of any current data, but keep the structure around
We're done!
Let's start with a bare minimum seed script.
For our example blog application, let's assume we need the following data:
- A post titled "Hello World!"
- A post author, with an email address that ends with "acme.org."
- Three comments on the post.
It's worth noting what we're not explicitly defining - that each comment needs to have a separate, unique author, for instance. We're assuming that @snaplet/seed
will fill in the blanks based on the schema and seed realistic data as needed.
seed
in the code above exposes all the models (i.e. the database tables, or the entities in our blog application - in this case "user" and "post") as functions.
These functions return what we call a plan. When describing a plan, we always start from a "root" model - a model where we would start describing how to seed seed data, along with data for its related models (more on this soon).
Here we start from the posts
models. await
ing a plan will execute it.
We can directly define the values of our model.
We can also define the values of our model's relationships.
Here we define the author of the post represented by the author
field.
Next, we also define the comments of the post represented by the comments
field.
As we need more than one comment, we can use the x
function which will create a list of similar comments.
We can read it as "comments times 3".
Finally:
- We'll add a
dryRun
option when creatingSeedClient
- in dry run mode, we'll log the sql statements to the console instead of altering the database. - and a
$resetDatabase()
call - this will clear the database of any current data, but keep the structure around
We're done!
Executing the script
At this point, we're ready to run our seed script for the first time!
Let's see first what statements are generated by using the dryRun: true
option.
We run this command in the terminal:
We should see the following output:
It's now time to seed this data into our database.
In order to do that, we remove the dryRun
option. Now, instead of logging the SQL statements to the
console, the data will be inserted into our database:
All done, we're now ready to code against our generated data!
Evolving the application
Whenever the database structure changes, @snaplet/seed
will need to be re-generated so that it is in sync with the new database structure.
We can do this by running:
This command will fetch the new structure from the database and use it to regenerate @snaplet/seed
assets.
Next steps
Learn more about how @snaplet/seed
works and define more complex plans by following one of our recipes.