Download the PHP package brahmic/laravel-filler without Composer

Laravel Eloquent Database Filler

Concept

When working with data via the API, we often receive these entities with nested relationships, but when sending data, the nested relationships have to be processed manually. This hydration pack allows you not to think about it. And this greatly speeds up development.

Peculiarities

• Allows you to work with input and output of Eloquent models “as is” - without unnecessary manipulations
• Unit of work - either all changes will be made, or (in case of an error) changes will not be made at all
• Idenity map - guarantees that entities of the same type and with the same identifier - are essentially the same
• uuid - allows you to create valid entities and link them together by identifier, without accessing the database

Content

• Idea
• Features
• Restrictions
• Installation
• Usage
  • Backend example
  • Frontend example

• Input features

  • Flat entities
  • HasOne
  • HasMany
  • BelongsTo
  • BelongsToMany
  • MorphTo
  • MorphOne
  • MorphMany
  • MorphToMany
• Output features

Restrictions

Currently only works with uuid

Installation

Usage

This thing is very easy to use

👆

Backend example

👆

Frontend example

(don't do this - this is just an example)

👆

Input features

Flat entities

Let's take a simple example:

Since the passed data does not contain the id field (or another field that was specified in the $primaryKey model), the hydrator will create a new entity. And fill it with the transferred data using the standard fill method. In this case, an id will be immediately generated for the model.

Example with ID:

In this example, id was passed - so the hydrator will try to find such an entity in the database. However, if it fails to find such a record in the database, it will create a new entity with the passed id . In any case, the hydrator will fill this model with the passed email and name. In this case, the behavior is similar to User::findORNew($id).

👆

HasOne

In this case, the hydrator will deal with the first-level entity (user) in the same way as in the example with the identifier. Then, it will try to find the account - if it does not find it (and in the current example the account does not have an id), it will create a new one. If it finds one with a different identifier, it will replace it with the newly created one. The old account will be deleted. Of course, in any post field (for example user_id or author_id - depending on how it is specified in relation to User::account()), the user ID will be written.

👆

HasMany

In the many-to-one example, a hydrator would come with each post entry, as in the HasOne example. In addition, all posts that were not present in the passed array of posts will be deleted.

👆

BelongsTo

Although this example looks like HasOne, it works differently. If such an organization is found by the hydrator in the database, the user will be linked to it through the relationship field. On the other hand, if there is no such record, the user will receive null in this field. All other fields of the associated record (organization) will be ignored - since User is not the aggregate root of Organization, therefore it is not possible to manipulate organization fields through the user object, nor is it possible to create new organizations.

👆

BelongsToMany

This example is like a mixture of HasMany (in the sense that all non-represented records will be removed from the pivot) and BlongsTo (all fields except the $primaryKey field will be ignored, for the reasons explained above in the belongsTo section) . Please note that working with a pivot is also available.

MorphTo

Supported, but not yet described. The principle of operation is similar to that described above.

MorphOne

Supported, but not yet described. The principle of operation is similar to that described above.

MorphMany

Supported, but not yet described. The principle of operation is similar to that described above.

Everything described works recursively, and is valid for any degree of nesting.

👆

Output Features

It's also worth noting that all passed relationships will be added to the entity during output. For example:

👆

TODO

• add the ability to persist an entity that has not passed through the hydrator
• add a description of polymorphic relationships to the readme

👆