refactor(backend): db session locking to support exclusive mode

[Shadow243]

Related task item89272

[Shadow243]

@kroky I tested with postgresql and mysql

I got a new error with postgres:

CREATE TABLE
psql:/home/runner/work/cypht/cypht/tests/phpunit/data/schema.sql:10: ERROR:  type "longblob" does not exist
LINE 1: ... EXISTS hm_user_session (hm_id varchar(255), data longblob,

[Shadow243]

This was is better but I'd like to change the approach. I see you copied large chunks of class contents from other frameworks. This is not the way to go because it makes maintenance harder and probably violates licenses. If you really wish to be fancy with php migrations, you can take a look here: https://packagist.org/?query=migrate for a suitable library and use one via composer. No need to maintain all that code.
Otherwise, my idea was much more simpler - do sql migrations - files stored in database/*.sql - run them one by one with timestamps and just execute whatever is there. No rollback. This should allow for the migration runner to be as simple as 1-2 methods with several lines of code - get all the migrations, check what has not been run against the current db and execute it via PDO.

You raised valid points, and I agree that maintaining a custom migration system could become complex over time.

If we consider using .sql files for database migrations, we must address compatibility across different database engines. SQL syntax can vary between systems like MySQL, PostgreSQL, and SQLite. To manage this, we could organize migrations into subdirectories by engine, such as:

/database/migrations/mysql
/database/migrations/postgresql
/database/migrations/sqlite

The migration runner would detect the current database engine and execute only the files from the relevant directory. This keeps the migration process straightforward while supporting multiple database systems.

Alternatively, leveraging a well-maintained package from Packagist could be a more robust and scalable solution. Libraries such as bizley/migration offer extensive support for multiple database systems and advanced features like schema management. Another option is doctrine/migrations, which provides powerful migration capabilities but may introduce additional complexity.

Each approach has its strengths. Using .sql files keeps things simple and transparent but requires custom implementation and careful handling of database-specific syntax(ex: 20241209040300_add_lock_to_hm_user_session_table.sql). Adopting a mature package simplifies maintenance and enhances functionality but adds external dependencies and a learning curve.

@kroky What can you advise me ?

Here is a screenshot that explains the incompatibility between databases using .sql files:

[kroky]

Yes, both options are valid. I think it is more in the spirit of cypt to go with the simpler approach and use per-database migration file. Cypht database is relatively simple, schema changes are not done often, so it doesn't make sense to me to include big dependencies as doctrine now.

[Shadow243]

Yes, both options are valid. I think it is more in the spirit of cypt to go with the simpler approach and use per-database migration file. Cypht database is relatively simple, schema changes are not done often, so it doesn't make sense to me to include big dependencies as doctrine now.

Understood, I will create the SQL files for each DBMS and test then ping you.

[Shadow243]

@kroky I updated schema for all databases(sqlite,pgsql and mysql). you can review.