Download the PHP package placebook/framework-selfupdate without Composer

ReadMe

The package is intended for semi-automatic updating of the database structure for the project core or third-party packages.

This package is part of the Placebook\Framework, but it can be used for any of your own projects. Also, it can be used not only for sql migrations, but also for any other reversible migrations.

How it works for the kernel

The project contains a folder for this package. for example, /install The path to this folder was passed to the package:

This directory contains the versions.json file and custom_versions.json with the following content:

Here is the version description. By default, class names are in namespace Placebook\Framework\Core\Install\, but another namespace can be specified. Kernel versions will always increase only the first version number and be in versions.json. Then a specific site can take the current version of the kernel, eg, 3.0.0, and increase the versions as you like, but without increasing the major part of the version (3). And store your versions in a file custom_versions.json. The package will merge both files and will be able to upgrade from scratch to the maximum kernel version, and then to the maximum version of a specific project. At the same time, a specific project that is already working and has its own migrations will be able to update its kernel version, and with it it will be updated and versions.json. For example, version 4.0.0 will appear there. Then the package will update the kernel, and then the project will have to assign versions >4.0.0 to its migrations Placebook\Framework core will not save its versions to file custom_versions.json, he is only yours This way, the package will work well and automatically with both kernel and project migrations.

Update process

The specified folder contains the file db_version.lock It stores the current version of the kernel. If there is no file, version is interpreted as 0

In the same folder there is a file updating.lock. If it exists, then the update is in progress, then the package will not start the update in another thread. Thus, if the migration goes on for a long time, then only the first request (after uploading new files) will start the migration. And the rest of the incoming requests will be processed on the base structure that is. The package reads all available versions and arranges them in ascending order. From one version to another, you need to go through all the intermediate ones. If the update is interrupted, the updating.lock file will remain, and the update will not start again until you sort out the situation manually.

For sites

Kernel update:

Adding migration

• The site needs to wrap the migration in a class that implements the interface Placebook\Framework\Core\Install\MigrationInterface
• You need to add the class name and namespace (if it is not Placebook\Framework\Core\Install, which is the default) in custom_versions.json under the new version
• In the class, it is desirable to implement both upward migration and migration rollback

Migration class example

For packages

Only one version file is needed, custom_versions.json is not needed. It is recommended to have this structure:

• /vendor/vendor_name/package_name/versions.json
• /vendor/vendor_name/package_name/**/ any useful classes, including those with migrations

Since there are modules on the site, you can move the work with SelfUpdate into a separate file that will be connected for all requests. Suggested content:

Installed versions of modules will be stored along the path install/modules//.version.lock If a module has migrations to the database and is available for installation through composer, then when you add it as a dependency to the project, it will be enough to add it to the array with modules once, and then you can update its versions through composer, and changes in the database structure will occur automatically