 |
 |
Seed Data
Seed data is anything that must be loaded for an application to work properly. An application needs its seed data loaded in order to run in development, test, and production.Examples can include:
- initial accounts for the application administrator and client users
- constant lists of countries, cities, colors, keywords, etc.
- default settings
Seed data is mostly unchanging. It typically won’t be edited in your application. But requirements can and do change, so seed data may need to be reloaded on deployed applications.
The ideal solution would be automatic: you shouldn’t have to think about it. When you start your application, your seed data should be ready
The seed data should provide integrity: for example, the created data records should work with your application validation testing.
We can create more seed data easily, for example if you want many seed users, organizations, sample data, and the like. For comparison, we have some applications with seed data for thousands of users and organizations.
Seed data should not need to be perfect in some cases. Some seed data may use random text, or "Lorem Ipsum" sample text, or blank text, just to get things in the right ballpark for our work.
Typically we add or remove seed data as new use cases come up. This helps us show that the application is working as we expect, and that the quality assurance team has valid starting data.
Seed Users
In our applications we typically have seed users with seed email addresses:- Seed user "John Doe"
- Seed email address "john.doe@example.com".
We typically have our seed script search for a seed user by email address.
If the email address exists, then our seed script decides that the user is already set up correctly.
If the email address does not exist, then our seed script creates the seed user.
If you delete a seed user, and re-run the seed script, then the script will create the seed user anew. This is to ensure that the application always has the seed users.
- Example: You delete "John Doe".
- When you re-run the script, then it creates "John Doe" again.
If you edit a seed user's email address, and re-run the seed script, then the script will create the seed user anew. This is to ensure that the application always has the seed users with the correct email addresses.
- Example: You edit "John Doe" and change his email address to "jane@google.com".
- When you re-run the script, then it creates "John Doe" again.
If you edit a seed user's fields (e.g. first name, last name, birth date, etc.), and re-run the seed script, then the seed script will keep your changes. This is useful for ongoing quality assurance and testing.
- Example: You edit "John Doe" and change his birth date.
- When you re-run the script, it sees "john.doe@example.com" still exists, so keeps your changes.
When you are planning the application, you can ask your developer to choose how and when the seed script will run, and which fields it will change, or keep, or recreate.
Seed Objects
In our applications we typically use seed objects for example:- Seed companies named "Company 1", "Company 2", "Company 3", etc.
- Seed groups named "Group 1", "Group 2", "Group 3", etc.
- Seed invoices named "Invoice 1", "Invoice 2", "Invoice 3", etc.
We typically have our seed script search for a seed object by name.
If the name exists, then our seed script decides that the object is already set up correctly.
If the name does not exist, then our seed script creates the seed object.
If you delete a seed object, and re-run the seed script, then the script will create the seed object anew. This is to ensure that the application always has the seed objects.
- Example: You delete "Company 1".
- When you re-run the script, then it creates "Company 1" again.
If you edit a seed object's name, and re-run the seed script, then the script will create the seed object anew. This is to ensure that the application always has the seed organizations with the correct names.
- Example: You edit "Company 1" and change the name to "Acme".
- When you re-run the script, then it creates "Company 1" again.
If you edit a seed object's fields (e.g. company address, group members, invoice price, etc.), and re-run the seed script, then the seed script will keep your changes. This is useful for ongoing quality assurance and testing.
- Example: You edit "Company 1" and change the street from "123 Main" to "456 First Ave".
- When you re-run the script, it sees that "Company 1" still exists, so keeps your changes.
When you are planning the application, you can ask your developer to choose how and when the seed script will run, and which fields it will change, or keep, or recreate.
Seed Connections
In our applications we typically connect seed users to seed organizations, for example "John Doe" works at "Company 1".If you expect to delete or edit seed data, then you can ask your application developer how to handle this.
Here are some examples that we've developed:
- If you delete "John Doe" and/or "Company 1", then the script will recreate them and reconnect them.
- If you change the user's email address and the company's name, then the seed script will recreate them and reconnect them.
- If you edit the user's fields and/or the company's fields, then the seed script will keep your changes.
- If you disconnect the user and company, such as assigning "John Doe" to work at a different company, then the seed script will keep your changes.
Seed Countries and Subcountries
In our applications we typically use seed countries and subcoutries that come from the list of international standards (ISO 3166-1 and 3166-2).Most of the countries and subcountries are as you'd expect. There are a few that are unusual, for example Puerto Rico shows up as a country and also as a U.S. state.