Download the PHP package guava/laravel-populator without Composer

Laravel Populator

Laravel populator's goal is to provide an unified way to populate your database with predefined data, while keeping your migrations intact.

There's a lot of tutorials and opinions about how to do that. Some people manually insert data into the database inside migrations and some use seeders. In both cases, a lot of people tend to use Model::create(), which at first sight seems like the easiest way and it even works. However, if you change your Model's structure in the future, there's a chance your migrations stop working. For example when tinkering with the fillable property.

Laravel populator solves this problem while maintaining a great developer experience when dealing with your database data.

Installation

You can install the package with composer:

You can optionally publish the database migrations if you plan to enable tracking

or publish the config

which currently provides the following options

config/populator.php

How it works

There are three major terms that Laravel Populator introduces:

Populators: These are basically named folders inside your /database/populators folder. They contain bundles.

Bundles: A bundle is collection of records of specific model. Bundles are part of the populator and are used to define the model of the records, default attributes or mutations.

Records: A record is the smallest unit and it represents a database record waiting to be populated. A record is a php file, which returns an array with key => value pairs describing your model / databse entry.

Example

2023_01_20_203807_populate_initial_data.php:

example record /database/populators/initial/post/example-post.php:

Usage

Using the generator command

Work in Progress

Manual

First you need to create a migration using:

Inside of the migration, you have to define your populator and it's bundles:

Now you need to create the directory structure. Since we named our populator initial and only have one bundle for the User model, our structure will be:

Now we can add as many records to the user bundle as we'd like. To do so, simply create a php file in the corresponding folder and name it how you want (it has to be unique across the bundle). Let's create john-doe.php to create our first user, John doe:

That's it! When the migration is run, it will create all records from the populator's bundles.

Please note that the password will not be hashed, in order to hash all passwords or to learn more about all the customization options, please refer to the documentation below.

Populators

Populators serve as a group of bundles of records that you want to populate. The reason for this kind of grouping is that during the lifetime of your application, you might want to add another batch of data to your application in mid-production. As we know, developers hate to come up with names and to avoid ending up with bundles named users1, users2, users-new, yet-another-batch-of-users, we decided to group them into populators so you only have to come up with a single name. :)

In case you end up needing to seed data in mid-production, we recommend naming your populators according to your version, such as v1.0, v1.1, v2.0 and so on.

Calling a populator

A populator is the entry point to everything this package offers. You can call the populator from anywhere you want, but we recommend calling them from migrations, like this:

This will call your populator and all it's defined bundles (more information in the Bundles section)

Reversing a populator

The records inserted by a populator can be removed if tracking is enabled when the populator was run.

Rollbacks will filter using the following condition

1. Population populator name
2. Bundle model classes
3. Bundle name

This allows you to control what bundles are rolled back from a populator.

For example you can rollback a subset of the bundles from the populator

Environment

Populators can be set to be executed only on specific environments. You might most likely want to seed different data for your local environment and your production environment.

You can easily do so using the environments method:

This populator will only be executed on the local environment.

Bundles

Bundles are like blueprints for all your records, they define default attributes or common modifiers so you don't need to repeat them in every record. This is done by chaining additional methods described below.

Creating a bundle is as simply as this:

Passing a name is optional and defines the name of the directory inside the populator's directory. If omitted, the name will be auto-generated from the model's class name. For example for the model Foo the name will be foo, for the model FooBar it would be foo-bar.

Environment

Similar to populators, you can also define specific environments for each bundle separately. To do so, chain the environments method on the Bundle itself:

Mutators

You can define mutators on any of the model's attributes in order to mutate the value before it's stored in the database.

For example you might want to hash all passwords:

Default

You can define default attributes for all records if they are not set. This is useful if you have a lot of records with the same attributes.

For example, you might want to add guard_name to all permissions (spatie/laravel-permission):

Generated

In case you want to have default or generated values for an attribute, you can chain a generated() method to your Bundle.

A common use case might be if you for example wanted to generate a slug from from another attribute:

Records

If you only have a small amount of records to create, it might be cumbersome to create the whole directory structure. For these cases you can create them from inside your migration using the record and records methods.

For example, to quickly create an admin account, you could do the following:

Override insert behavior

If you need to customize the insertion behavior for records you can call performInsertUsing() on a bundle.

For example, to perform an updateOrCreate instead of an insert

Relations

Records can of course have relations with other records. Currently supported relations are:

• one to one and it's inverse
• one to many and it's inverse
• many to many (belongsToMany)
• polymorphic one to one and it's inverse
• polymorphic one to many and it's inverse (morphMany)

Referencing other records

Other records can be referenced in multiple ways, the package tries all three of them in this specific order.

By their identifier (key)

This works only from within the same populator (across all bundles). The key is the name of the file, so in case of the john-doe.php example file from earlier, the key would be john-doe.

In case you supplied the records to the bundle directly via the records() method, the key is the array key you set.

By their primary key

If no key was found, the package assumes the provided key is the primary key and attempts to find the record in the database. If the record exists, the primary key will be used.

by a (preferably unique) column

You can also reference records using any column you like. For example, to reference John Doe from other records, you could reference their e-mail using email:[email protected]. The package will then attempt to find the record with that e-mail address.

One to One

Let's say we have a User model that has one Address relation. You can define the relation in the Address bundle like this:

This will attempt to associate the address with the user record admin.

You could also reference the user their primary key:

Or using a column of your choice:

One to One (Inverse)

Let's say we have a User model that has one Address relation. You can create an Address from the User record:

This will create a user and associate it with a newly created address record with the specified attributes.

One to Many

Imagine we had a Posts bundle that had a one to many relation to the author (John Doe) created in the very first example. We simply use the record's key to associate it with the post.

Many to Many

If we wanted to modify the above example and also add a many to many relation to tags, it's as simple as this:

This will attach the post with the specified tags.

Polymorphic One to Many

Now imagine we had a Comment model which has a polymorphic relation to the Post model.

Adding such a relationship is similar to a belongs to relation, but we need to pass an array with the key/primary key AND the class of the morph.

Polymorphic One to Many (Inverse)

Last but not least, assuming we have Like model with a polymorphic relation to our Post model. Let's take another look at our example-post record and extend it one last time by adding an inverse likes relation.

This will automatically create two Like's with the defined attributes and a relationship to the post they have been created in.

Tracking inserted models

Inserted models by a populator can be tracked in the database by enabling the tracking feature in Laravel populator.

Laravel populator provides a trait [HasPopulation.php](src%2FConcerns%2FHasPopulation.php) to access the Population from models

The model then has access to the Population relationship by $model->population

Enabling tracking

Tracking can be enabled either by enabling the feature inside the published configuration file or by enabling it in the boot method of a service provider.

Enabling by config:

config/populator.php

Enabling by provider:

AppServiceProvider.php

Marking models for tracking

Models must implement TracksPopulatedEntries.php to opt in for saving populations.

Swapping the Population model

The population model can be changed by setting the model class inside the published configuration file or by enabling it in the boot method of a service provider

Enabling by config:

config/populator.php

Enabling by provider:

AppServiceProvider.php

Other packages

• Filament Icon Picker
• Filament Drafts