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. awaiting 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
dryRunoption 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.