{
"data": [
{
"type": "blog",
"id": "blog/2024/symfony-and-doctrine-migrations-validation-in-ci",
"url": "https://ktherage.github.io/blog/2024/symfony-and-doctrine-migrations-validation-in-ci/",
"attributes": {
"alias": "/blog/symfony-and-doctrine-migrations-validation-in-ci/",
"title": "Symfony & Doctrine Migrations: Validation in CI",
"date": "2024-09-05T00:00:00+00:00",
"description": "How to detect when a Doctrine entity change ships without a generated migration: a simple CI check that fails fast on inconsistent schema vs. mapping state.",
"cover": {"image":"img/birds-migration.jpg","alt":"Flock of birds forming V shape in flight","caption":"Photo by Kai Filmer on Pexels"},
"published": true,
"tags": ["Symfony","Doctrine","Migrations","CI","DevOps"],
"excerpt": "I had the opportunity to work on a project with a team that was relatively new to Doctrine migrations. To help them get used to it, and to discard the possibility of having pull (or merge) requests with changes to doctrine entities without generating a migration.\nHere is how I did it. I hope you'll enjoy it!",
"body": "I had the opportunity to work on a project with a team that was relatively new to Doctrine migrations. To help them get used to it, and to discard the possibility of having pull (or merge) requests with changes to doctrine entities without generating a migration.\n\nHere is how I did it. I hope you'll enjoy it!\n\n## Disclaimer\n\nWe are the 10th of July 2025 now and this article is outdated due to the merge of the Pull Request https://github.com/doctrine/migrations/issues/1406 and so running `bin/console doctrine:migrations:up-to-date` shall now take care of `schema_filter` configuration.\n\n\n## How Doctrine Migrations works\n\nWhen generating the migration, Doctrine will make a delta between its mapping and the current schema of the database. With this delta in "mind" (dare I say :wink:) it will generate a **migration file** with two main methods :\n* `up` applies the SQL commands to fill the gap between the current database schema and its mapping. Used to deploy changes in the schema of your database.\n* `down` allows to revert the migration with the SQL commands needed to "negate" the changes made in the up method. Used to roll back changes in the schema of your database.\n\n## The magic trick\n\nThere is currently no way to easily check if a migration has not been generated. Having this code merged could lead to a database schema being out of sync with your entity mapping and so resulting in a server error.\n\nThe keywords in the above description are **migration files**. I'll use the fact that, running the command bin/console doctrine:migration:diff will result in a newly generated file and will fail if there are no changes to apply.\n\nKnowing the list of existing files before the execution of that command, and then running it, can let me know that there are changes that were not committed to a **migration file** in this pull (or merge) request.\n\n## Steps to do\n\n1. Create your database\n2. Run your existing migrations\n3. Then run the step to check for missing changes (see below)\n\n## Advantages\n\n1. Testing that your migrations does not fail\n2. Ensure database schema consistency with Doctrine's mapping\n\n\n## You want the code snippet right!?\n\nHere is the bash code :\n\n```bash\n#!/bin/bash\n\nset -e\nset -o pipefail\n\n# run doctrine migration diff to check if there is a new migration file generated and check last exit code\nif [[ -z $(bin/console doctrine:migrations:diff -n --quiet) ]]; then\n echo "Error ! bin/console doctrine:migration:diff found a new migration which must not be the case.";\n # cat last file (should be the newly generated one)\n cat $(ls -Art migrations/*.php | tail -n 1);\n # remove that file (just in case to comply with my paranoïac side)\n rm -f $(ls -Art migrations/*.php | tail -n 1);\n exit 1;\nelse\n exit 0;\nfi\n\n```\n\nAnd that's it! You can now ensure that each pull (or merge) request has working migrations, with no pending changes left out of the migrations!\n\n## Ok but why not use `bin/console doctrine:schema:validate`?\n\nThe reason was that the project we were working on was using doctrine's schema_filter configuration to filter out some tables we did not want to deal with (project-related inconvenience).\n\nThe problem with bin/console doctrine:schema:validate was that it did not take care of the configuration, and so was dumping changes (trying to delete all the "normally" filtered out tables) not related to what we wanted.\n\nA colleague told me that this is a known issue that might be fixed soon (https://github.com/doctrine/migrations/issues/1406).\n\n\nThank you for reading this article and please leave your comments if you have any questions!"
}
},
{
"type": "blog",
"id": "blog/2024/bash-and-curl-simple-http-call-performance-testing",
"url": "https://ktherage.github.io/blog/2024/bash-and-curl-simple-http-call-performance-testing/",
"attributes": {
"alias": "/blog/bash-and-curl-simple-http-call-performance-testing/",
"title": "Bash & Curl: Simple HTTP call performance testing",
"date": "2024-01-19T00:00:00+00:00",
"description": "A quick and simple way to test the performance of your HTTP calls.",
"cover": {"image":"img/terminal-code.jpg","alt":"Computer program language text","caption":"Photo by Nathan Dumlao on Pexels"},
"published": true,
"tags": ["Bash","Curl","Performance","Testing"],
"excerpt": "HTTP calls are essential to the functioning of the web and are critical to any web development project. You may have wondered how to quickly see how your HTTP call is performing. I'll show you how I did it easily using Curl.",
"body": "HTTP calls are essential to the functioning of the web and are critical to any web development project. You may have wondered how to quickly see how your HTTP call is performing. I’ll show you how I did it easily using Curl.\n\n**TL;DR:** You just want the code (I perfectly understand that 😉)? Scroll to the piece of code.\n\n# What was my need regarding HTTP calls?\n\nI needed to have a quick idea of how the application cache system I’ve placed on an HTTP endpoint was performing, and I wanted it to be quick and simple.\n\nWith my notions of Shell and basic knowledge of Curl (a small gift from a colleague: you can find a Curl cheatsheet here), I knew that I could easily run a hundred times the same HTTP call and get the total time as a result.\n\nThis solution is a simple short solution that fits my needs which was to locally test my HTTP endpoint.\nIf you plan to do real performance/load testing on real servers like staging or production ones then you shall take a look at tools like (https://jmeter.apache.org/)[Apache JMeter], (https://gatling.io/)[Gatling], or other similar tools.\n\n# How Curl helped me test my HTTP call?\n\nSo I opened my terminal and ran:\n\n```bash\nfor i in {1..100}; do curl 'https://some-domain/some-uri/some-path?cache=false' \\\n-H 'cache-control: no-cache' \\\n-H 'pragma: no-cache' \\\n--compressed \\\n--insecure -s -o /dev/null -w "%{time_total}s\\n";\ndone\n\n# Which printed :\n0.057703s\n0.067895s\n0.063033s\n0.062455s\n0.074864s\n...\n```\n\nFor some explanations, I copied the request sent by my browser as a Curl request (this could be easily done on most browsers see (https://quickref.me/curl)[here]) and wrapped it in a for loop which is running that HTTP call a hundred times.\n\n**The only change I made to the Curl request** was to add the options `-s` for a quiet output, `-o /dev/null` to avoid having the response body printed and the most important one `-w "%{time_total}s\\n"` which allows me to format Curl’s output to return the total time. You can have a full list of available “Write out variables” (https://everything.curl.dev/usingcurl/verbose/writeout.html#available-write-out-variables)[here].\n\nAnd that’s it 🎉 ! **You can have a quick performance idea only with the tools you may already use.**\n\nI hope you’ll find it helpful!\n\nPlease feel free to leave your comments or questions below."
}
}
]
}