There is a ton of legacy projects that exist in the universe written in PHP. Old codebases are hard to maintain, and it's not easy to set up a development environment for legacy applications. I had the same issue; I have a lot of solutions to build a stateless development environment for legacy projects. Today I will focus on database-related one.

Let's think you start to work on a legacy project and have made some changes to the database on your local. What do you need to do? You will probably fetch the production database to your local (with/without data), write some SQL to alter your DB structure, save queries, and apply them to your production database.

It's a simple task if you have a simple application. But web applications are mostly like living organisms. Invariably they will be getting more and more complex. You will sometimes forget to apply a statement to your production database. It will cause many problems until you realize which statement you forgot.

There is a solution for following the structural database changes. It's called Schema Migration. You can start to use a migration library to follow database structure changes. Also, you can go future and past in your DB schema with a migration tool (be careful, it will remove all data dependent in that update if you go back. it will remove field data if you remove a field.)

Migration libraries mostly have simple logic. You will have versioned up and down scripts, and it will run those scripts. But it may be hard to add libraries to legacy apps.

So, I created a library for the same purpose. Other libraries are too big and complex; I built a library on top of the PDO library, which has a few simple commands. I want to show you how you can add that library to your legacy app and start to use it. Let's begin.

The library name is Migratos, its a god of all migration libraries :)

You can install with composer require 7cups/migratos command. But you will need to create a wrapper for that. Eventually, it's just a library.



use SevenCupsMigratos\Command\MigrationCommand;
use Symfony\Component\Console\Application;

$db = new PDO('mysql:host=localhost;dbname=test', 'databaseuser', 'databaseuserpass'); 

$application = new Application('My Console','1.0');

$application->add(new MigrationCommand($db)); 


Migratos only care for PDO instances. Maybe you have a wrapper library over PDO; it will work if extended from PDO.

We loaded our application autoloader (which was generated by the composer) and then created our PDO instance; then, we will add a migration command to CLI application. (It is using symfony/command library to manage CLI, you can use MigrationCommand with your console app if you have one)

But before, do not forget to create a folder named migration in your root directory. mkdir migration

Then we just run the CLI app.

Let's do some tests. You can run that command: php console.php --help. You will get help text of usage of symfony/console. Then you can run the php console.php list command to get what tools exist in the console.php, and you will see that app:migration subcommand.

Lets test this: php console.php app:migration --help. There are five options that exist for use with that subcommand.

At the first usage, you will need a base.sql file. Because you have a database schema already. Try php console.php -b command. It will ask to write a new SQL file with some content. Answer yes. In that step, only the migration table create statement exists in base.sql file.

 CREATE TABLE migratos_migration_versions (
    version int(11),
    direction ENUM('u','d'),
    current_version varchar(255),
    PRIMARY KEY (id)

Now, you have to export your database structure manually (I will add an automated base.sql creation soon), then paste the content of that file. Let's say we have just a table; then, our base.sql will look like this;

 CREATE TABLE migratos_migration_versions (
    version int(11),
    direction ENUM('u','d'),
    current_version varchar(255),
    PRIMARY KEY (id)
   username varchar(255),
   type ENUM('admin','member'),
   password varchar(255),

You see. This is our base database structure. But do not forget to add IF NOT EXISTS statement to the table creating query. Your database already exists; you would not want to override existing data.

Now, we will run php console.php app:migration --init command to initialize our local database. Do not run this command on production!!!

And your local database structure is ready to use. You can copy your local migratos_migration_versions table to your production database if you want to use that tool in the production server. It contains data for initial data, which is your existing production database. All runs after an initial run will update your database structure from that point. This is zero-point.


Let's create a new migration file. Let's say we need to add an email field to the user table. Run that command: php console.php app:migration -c, and create two empty files, one for up and one for down scripts. Under migration folder d_1660740441.sql u_1660740441.sql, you will see two new files.

Add your up SQL script to u_1660740441.sql file;

ALTER TABLE users ADD COLUMN email varchar(255) null;

And add your down SQL script to d_1660740441.sql file;


Ready, you can run the migration command php console.php app:migration -u to append changes to the database. It will print out SQL statements before running on the database.

Then changes will be applied to your database. You can commit that file, and all developers in the team can create their own migration files, and the system admin will know which changes happened to the database structure.

Do you want to roll back changes? Easy peasy!

php console.php app:migration -d 1660740441 this command will revert changes made by u1660740441.sql file and upper versions. For instance, you have 2 migration files u1 and u_2. If you run down the command for 1, it reverts all updates bigger than 1.

Good for you!

There is a demo repository in GitHub; https://github.com/delirehberi/legacy-app

#php #library #database #command #en

I don't like to install servers on my local and run these as a systemd service. This is why i am a big fan of the Docker.

But sometimes i just want to use servers as a specific app. Without install system-wide.

You know that, as instance; when you install #postgresql, it is create a user, installs files to your root directories, changes the ownerships and creates service files bla bla bla.


tldr; NO!, of course not!

The first question is what is the problem which trying to be solved by IMs.

I believe that the problem is connectivity. So clear enough. All IM brands are tries to solve connection problem between people. People wants to reach each other whenever they want. This is all about “EVOLUTION”, ehe, ehe, ehe.


I couldn't write a post in English for a long time. You know, easy to write in my mother-language of course, but i can not to improve my language skills if i don't write. This is an important thing to making progress in language learning.

I'm in a path nowadays. Am i need to stay in my country or am i need to move to another place.

I'm a kind of nationalist and in my heart, believe me, i want to stay in here. I do not want to left my whole life behind and start a completely new thing. I'm 30+. I feel my-self tired to start a new life. But in same time i am not sure about it.

Maybe it'll be better to future myself. I worry about my country and i have no chance to change something in here. I feel myself powerless. I feel myself useless. I cannot see any possibility about our country's future. I have no hope in a short period.

Of course, in a time, people my country and the country will rise, but i do not believe that i'll live enough to see that :)

Anyway, i have to make a decision for my future in a few years. I need to be quick.

#en #chitchat

I quit smoking 20~ days ago. It was the time for that. I was feel that. So I decide to not smoke anymore and i didn't, i will not. I don't want to smoke anymore, i did for 12 years and it is enough. I want to live healthy, i want to breath to fresh air.

These are my advises to who wants to quit;

Do not push yourself; at first, you have to accept the smoking is wrong, otherwise you can not leave it. You have to understand that with your whole consciousness, read about that, think about it, spend your time before quit smoking with trying to accept the “smoke is wrong”. You have to feel in your hearth “this is wrong, i do not want to that”

Then, everything will be great...

#personal #en

Nix is a package management language that has a massive ecosystem about solving DevOps problems.

Nix, is a functional and domain-specific programming language. Nix also is a package manager for Linux and Unix based systems like aptitude and brew.


For instance, you need to write a search page for your last project, and it is not big enough to use an external search engine. Still, you want to use some powerful text searching features. You are brilliant if you preferred PostgreSQL as your database. Because PostgreSQL has very, very powerful search capabilities. I want to share some of them with you.


You might want to build your Haskell application with #Nix even if you did start with #Stack.

#Stack has support for building with #Nix. You need to add nix.enable: true to your stack.yaml file.


You need to use a Voter for workflow entity for managing access policies when you use the Workflow component. Workflow component supports access policies with guard option, but the documentation won't point out how to get the subject variable for a voter class.


Composer is an installer and a package management tool. So please stop writing build scripts for Composer, building anything inside your package folder.

Last few days, I try to deploy a Symfony project with Nixops to Google Cloud. I found the composer2nix package after some research.