Download the PHP package anexia/laravel-changeset without Composer
On this page you can find all versions of the php package anexia/laravel-changeset. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download anexia/laravel-changeset
More information about anexia/laravel-changeset
Files in anexia/laravel-changeset
Package laravel-changeset
Short Description A laravel module to monitor model changes and log them into the database
License MIT
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package laravel-changeset
Anexia Changeset
A Laravel package used to detect permanent changes to your Eloquent models (written into the database) and log them into separate database tables.
Installation and configuration
Install the module via composer, therefore adapt the require part of your composer.json:
In the projects config/app.php add the new service provider. This will include the package's migration files to the
project's migration path:
Now run
to add the packages source code to your /vendor directory and update the autoloading.
Custom Database Configuration
By default the changeset tables get added into the application's main database. The default changeset db connection is 'changeset_mysql', which is defined in the package's /config/connections.php:
So the changeset db uses the 'DB_' variables in .env by default. To use a different changeset db, another set of .env varibales can be configured:
The /config/connections.php comes with a preset variety of possible db configurations (changeset_sqlite, changeset_mysql, changeset_pgsql, changeset_sqlsrv), similar to Laravel's default db configurations. On application boot, these entries get added to the application's 'database.connections' configuration field.
If a different configuration is needed, it can always be defined in the usual Laravel manner in the application's /config/database.php and then set via the .env variables, e.g.:
How it works
The Changeset package comes with three new models:
The Changeset package adds hooks to the models 'created', 'updated' and 'deleted' events. So any change (save(), update(), delete(), forceDelete()) of a trackable model (that uses the ChangesetTrackable trait, like Post.php) triggers a changeset creation.
Depending on the performed change, multiple changerecords get created and associated to the new changeset:
- If a new model gets saved, all its properties receive a changerecord that gets associated to its 'CREATE' changeset (since they were all 'changed').
- If an existing model gets updated, all the changed properties (different values than before the change) receive a changerecord that gets associated to its 'UPDATE' changeset.
- If an existing model gets deleted, no changerecord gets associated to its 'DELETE' changeset.
Regardless of the performed change's type, further changesets for configured parent relations (via $trackRelated) will be triggered. Parent relations themselves can define their own $trackRelated associations, so a multi-layer tree of related changesets might be triggered (see Usage 'Related Changesets').
Usage
Use The ChangesetTrackable trait in a base model class. All models that are supposed to be changeset-trackable must then be extended from this base model class.
The detour over an "intermediate" BaseModel class is necessary to allow the protected fields of the ChangesetTrackable trait to be overwritten for each trackable model. That means that $trackBy, $trackFields and $trackRelated can NOT be altered/redefined in the BaseModel class itself, but in each of its child classes like Post.
Object Types
The changeset package uses the ObjectType model to manage all classes that use the package's ChangesetTrackable trait. The application "learns" and remembers trackable class names during its lifecycle. After the first occurrence of a tracked change for each class that uses the ChanesetTrackable trait the class name will be stored in a new "ObjectType" entry.
Seeding
To learn all possible Object Types (= names of classes that use the ChangesetTrackabke trait) at once, the package comes with a ChangesetObjectTypeSeeder. This seeder iterates through all classes within the directories "app" and "vendor" and and checks whether they (or one of their parent classes) use the ChangesetTrackable trait. If so, the classes name gets stored as a new Object Type.
To run the Seeder one has two options: 1) Run it explicitely
2) Include it into the general database seeder, which is usually /database/seeds/DatabaseSeeder.php
With the common seeding command
the object type seeder gets processed together with all other defined seeders (in given order).
Related Changesets
Since Post.php has a relation to another model User.php (via 'author') and configured this relation as 'trackable', any change on a post object will not just trigger a changeset for that post, but also for its associated author. So
- If a new model gets saved, a new 'CREATE' changeset with object type App\Post gets created, all its properties receive a changerecord that gets associated to that changeset. Also a new 'UPDATE' changeset with object type App\User gets created, with a changerecord for field_name 'posts', is_related = true and the display info that a post object got newly associated.
Assuming that a new post with id 1 gets created by admin (= user 1) for user with id 2, the following object types, changesets and changerecords would be generated:
-
If an existing post gets updated, a new 'UPDATE' changeset with object type App\Post gets created, all the changed properties receive a changerecord that gets associated to that changeset. Also a new 'UPDATE' changeset with object type App\User gets created, with a changerecord for field_name 'posts', is_related = true and the display info that a certain associated post got changed. Assuming the existing post with id 1 gets changed by admin (= user 1), the following changesets and changerecords would be generated:
- If an existing post gets deleted, a new 'DELETE' changeset with object type App\Post gets created. Also a new 'UPDATE' changeset with object type App\User gets created, with a changerecord for field_name 'posts', is_related = true, is_deletion = true and the display info that a certain associated post got deleted.
List of developers
- Alexandra Bruckner [email protected], Lead developer
