3f4c86f80f
Before, we had 5 classes in the ModelPdo file. It was bad for 2 reasons. The first reason is that it is considered bad practice to have multiple class in one file. This is especially true when using autoloading. On top of that it is less readable considering the size of the file. The second reason is that so far we were lucky. Everytime we needed to access the database, it was through the ModelPdo class which loads all the other classes. If we want to access directly the connection, it wont be loaded. On top of that, the system is configured to work on a single database, but as we have every connection definition in a single file, all classes were loaded at the same time. Thus using memory and processing time for nothing. Now, we have a file for each class. To work with autoloading, classes were slightly renamed to match autoloading rules.
1.7 KiB
How to manage migrations with Minz
Migrations are the way to modify the database or the structure of files under the data/ path.
How to write a migration?
Migrations are placed under the app/migrations folder.
Good practice is to prepend the filename by the current date and explain what does the migration do in few words (e.g. 2020_01_11_CreateFooTable.php).
The files must contain a class which name starts with FreshRSS_Migration_, followed by the basename of the file (e.g. FreshRSS_Migration_2020_01_11_CreateFooTable).
The class must declare a migrate static function. It must return true or a string to indicate the migration is applied, or false otherwise. It can also raise an exception: the message will be used to detail the error.
Example:
// File: app/migrations/2020_01_11_CreateFooTable.php
class FreshRSS_Migration_2020_01_11_CreateFooTable {
public static function migrate() {
$pdo = new Minz_PdoSqlite('sqlite:/some/path/db.sqlite');
$result = $pdo->exec('CREATE TABLE foos (bar TEXT)');
if ($result === false) {
$error = $pdo->errorInfo();
raise Exception('Error in SQL statement: ' . $error[2]);
}
return true;
}
}
How to apply migrations?
They are automatically applied one by one when a user accesses FreshRSS.
Before being applied, migrations are sorted by filenames (see the strnatcmp function). Already applied migrations are skipped (the list can be found in the data/applied_migrations.txt file).
To ensure migrations are not applied several times if two users access FreshRSS at the same time, a folder named data/applied_migrations.txt.lock is created, then deleted at the end of the process.