DEV Community: Szj

Your architecture rules are code too: mutation-testing a DDD ruleset in PHP 8.4

Szj — Thu, 05 Nov 2026 08:36:35 +0000

In September 2017 Lukas Taake published the first part of a write-up of his master's thesis about static code analysis for Domain-Driven Design. It was built as a SonarQube plugin for Java, and its thesis is the most honest sentence in the genre: static analysis cannot show that DDD is done correctly; it can help keep some basic principles intact over time.

I wanted to know what that looks like in PHP today, nine years later. Two things have changed: the language now enforces a lot by itself (readonly, enums, asymmetric visibility, attributes), and we have mutation testing, which gives us a way to ask the question the 2017 post could not: if someone breaks a rule, would your checks notice?

Everything below was run, not described. The demo domain is small (13 files), the mutants are hand-written, and I list the limits at the end.

The eight rules, then and now

Taake's rules, as I read them in his post:

Every entity type has an identity.
Value objects are immutable.
No anemic domain model (entities that are only getters and setters).
Aggregates are trees and link to other aggregates only by identity.
An aggregate has a maximum size.
Domain services exist only where behaviour cannot sit in an entity.
Repository implementations live outside the domain model.
The domain model depends on nothing else in the application.

The 2017 approach discovers the "model parts" by class hierarchy, name patterns or annotations, and the author admits the weak spot: you must tell the tool what is an entity and what is a value object, and the analysis is only as good as that configuration. In PHP 8 an attribute is the natural answer, because it is part of the class and the compiler sees it:

namespace App\Sales\Domain;

#[\Attribute(\Attribute::TARGET_CLASS)] final class AggregateRoot {}
#[\Attribute(\Attribute::TARGET_CLASS)] final class Entity {}
#[\Attribute(\Attribute::TARGET_CLASS)] final class ValueObject {}

#[ValueObject]
final readonly class Money
{
    public function __construct(public int $amount, public string $currency) {}
    public function add(self $o): self { return new self($this->amount + $o->amount, $this->currency); }
}

#[AggregateRoot]
final class Customer
{
    public function __construct(private CustomerId $id, private string $name) {}
    public function id(): CustomerId { return $this->id; }
    public function rename(string $name): void
    {
        if ($name === '') { throw new \DomainException('empty name'); }
        $this->name = $name;
    }
}

The demo domain has two aggregate roots (Customer with Address value objects, Order with OrderLine entities), value objects for money, ids and the order number, an OrderRepository interface in the domain and an implementation in Infrastructure. Customer and order refer to each other by id (CustomerId, OrderId), as rule 4 asks.

Versions used: PHP 8.4.16, PHPStan 2.3.5, phpat 0.12.5, Deptrac 4.7.2, PHP Arkitect 1.3.1.

Rule 2 first, because PHP does half of it

final readonly class Money makes the compiler and the engine refuse most of what rule 2 was written for. Writing to a readonly property from outside, or from a setter, throws:

Error: Cannot modify readonly property Money::$amount

Two caveats, both worth knowing:

This is a runtime error. The code that does it is still valid PHP; the engine only complains when it runs. A static check is still useful (PHPStan reports an assignment to a readonly property outside the constructor on its own, with no custom rule).
Asymmetric visibility (public private(set) int $amount, PHP 8.4) is not immutability. The class itself may still change the value: Cannot modify private(set) property appears only for a write from outside.

And one that no keyword fixes: readonly is shallow. A readonly value object holding an ArrayObject is still mutable through it. More on that below.

Rules 1 and 4: where only a custom rule helps

Layer tools know about namespaces; they know nothing about aggregates or identity. For rule 4 (an aggregate root must not hold another aggregate root), a PHPStan rule is about twenty lines:

/** @implements Rule<InClassNode> */
final class AggregateReferencesByIdRule implements Rule
{
    public function __construct(private ReflectionProvider $rp) {}
    public function getNodeType(): string { return InClassNode::class; }

    public function processNode(Node $node, Scope $scope): array
    {
        $class = $node->getClassReflection();
        if (!Marker::has($class, 'AggregateRoot')) { return []; }
        $errors = [];
        foreach ($class->getNativeReflection()->getProperties() as $p) {
            $type = $class->getProperty($p->getName(), $scope)->getReadableType();
            foreach ($type->getReferencedClasses() as $name) {
                if ($name !== $class->getName() && $this->rp->hasClass($name)
                    && Marker::has($this->rp->getClass($name), 'AggregateRoot')) {
                    $errors[] = RuleErrorBuilder::message(sprintf(
                        'Aggregate root %s holds another aggregate root %s in $%s; reference it by id.',
                        $class->getName(), $name, $p->getName()))
                        ->identifier('ddd.aggregateByObject')->build();
                }
            }
        }
        return $errors;
    }
}

Marker::has() is a three-line helper that looks for the attribute on a class. Rule 1 (an entity has a public id() method) is the same shape: if a class is marked #[Entity] or #[AggregateRoot] and has no public id(), report it. The rules are registered in phpstan.neon like any other:

parameters:
    level: 8
    paths: [src]
services:
    - { class: Rules\AggregateReferencesByIdRule, tags: [phpstan.rules.rule] }
    - { class: Rules\EntityHasIdentityRule, tags: [phpstan.rules.rule] }
    - { class: Rules\ValueObjectIsImmutableRule, tags: [phpstan.rules.rule] }

Rules 7 and 8: layers, with two tools that disagree

Deptrac states the dependency direction as data (use the deptrac/deptrac package; the old qossmic/deptrac is flagged as abandoned by Composer):

deptrac:
  paths: [./src]
  layers:
    - name: Domain
      collectors: [{ type: classLike, value: '^App\\Sales\\Domain\\.*' }]
    - name: Application
      collectors: [{ type: classLike, value: '^App\\Sales\\Application\\.*' }]
    - name: Infrastructure
      collectors: [{ type: classLike, value: '^App\\Sales\\Infrastructure\\.*' }]
    - name: Doctrine
      collectors: [{ type: classLike, value: '^Doctrine\\.*' }]
  ruleset:
    Domain: ~
    Application: [Domain]
    Infrastructure: [Domain, Application, Doctrine]

phpat expresses architecture rules as PHP, as a PHPStan extension:

public function testDomainDependsOnNothing(): PHPatRule
{
    return PHPat::rule()
        ->classes(Selector::inNamespace('App\Sales\Domain'))
        ->canOnlyDependOn()
        ->classes(
            Selector::inNamespace('App\Sales\Domain'),
            Selector::classname('/^[^\\\\]+$/', true), // PHP built-ins in the global namespace
        )
        ->because('the domain depends on nothing else');
}

public function testRepositoryImplementationIsNotInDomain(): PHPatRule
{
    return PHPat::rule()
        ->classes(Selector::inNamespace('App\Sales\Domain'))
        ->shouldNotImplement()
        ->classes(Selector::classname(OrderRepository::class))
        ->because('repository implementations live outside the domain model');
}

(The regular expression lets DomainException and other global classes through, otherwise phpat flags them as outside dependencies.) I ran PHP Arkitect on the dependency and immutability rules too; it caught the same mutants as the other two there.

Rules 3 and 5: a number you choose

I did not find a standard tool for "anemic entity" or "aggregate too big", so the demo has a thirty-line script. It counts, per #[Entity] or #[AggregateRoot] class, behaviour methods against getters and setters, and the members (entities and value objects) reachable inside an aggregate:

anemia  App\Sales\Domain\Customer   behaviour=3 accessors=3 share=0.50 ok
anemia  App\Sales\Domain\Order      behaviour=2 accessors=3 share=0.40 ok
size    App\Sales\Domain\Order      members=3 (max 5) ok [Money,OrderLine,OrderNumber]

Both thresholds are arbitrary and that is the point of rules 3 and 5: they are project decisions, written down and enforced, not facts about DDD.

The question the rules cannot answer about themselves

All of the above is green on the clean domain. That says nothing about whether the rules would go red on a violation. This is exactly the question mutation testing answers for code: change the code a little, run the tests, and count the changes nobody noticed. The idea carries over to a ruleset. A mutant here is a violation of one rule, applied to a copy of the domain as a textual patch, and the check is whether any tool exits with an error.

The runner is short: copy the clean src/, apply one patch, run every tool, record "caught" when its exit code is not zero, restore, repeat. A mutant looks like this:

'M3  Customer holds an Order object' => function () use ($D) {
    edit($D . 'Customer.php', 'public function id(): CustomerId',
        'private ?Order $lastOrder = null;' . "\n    " .
        'public function lastOrder(): ?Order { return $this->lastOrder; }' . "\n    " .
        'public function id(): CustomerId');
},

Twelve mutants, seven checks (php -l, a runtime probe that instantiates the value object and tries to change it, PHPStan with the three custom rules, Deptrac, phpat, Arkitect, the metrics script):

Mutant	probe	PHPStan + rules	Deptrac	phpat	Arkitect	metrics
M1 setter on a (non-readonly) VO	caught	caught		caught	caught
M1b setter on a readonly VO	the language	caught
M2 public mutable VO property	caught	caught		caught	caught
M3 Customer holds an Order object		caught
M4 domain imports Doctrine			caught	caught	caught
M5 entity without identity		caught
M6 repository implementation in the domain				caught
M7 anemic entity						caught
M8 aggregate over the size limit						caught
M9 an equivalent rewrite (`+=`)
M10 readonly VO holding a mutable object
M11 an invariant dropped

php -l caught nothing, because every mutant is valid PHP.

What the table says

Different tools see different mutants. M3 and M5 are caught only by my two custom PHPStan rules; the layer tools know nothing about aggregates or identity. M7 and M8 are caught only by the metrics script. M6, a repository implementation put into the domain namespace, is caught only by phpat: Deptrac sees a domain class implementing a domain interface, which is an allowed dependency. I did not write an Arkitect rule for it, and it can probably do the same. No single tool has the whole picture, which is an argument for a small set instead of a big one.
The language is the cheapest rule. M1b is stopped by PHP at runtime and by PHPStan statically without any custom rule; final readonly class plus an attribute is enough for most of rule 2.
Three mutants slip through everything, and each has a different reason:
- M9 is equivalent: a rewrite that changes nothing observable. Correctly caught by nothing. This is the same class as in ordinary mutation testing.
- M10 is a real blind spot: readonly is shallow, and a value object that holds a mutable object is still mutable. A rule could look at property types, but then you have to decide what counts as mutable.
- M11 drops an invariant (a validation in the constructor). That is behaviour, and static rules cannot see it. Only unit tests, or mutation testing of the domain's own tests, will.

That last point is where the two kinds of mutation meet: architecture rules protect the shape of the model, and classic mutation testing (Infection in PHP) protects the behaviour inside it. A rule set with a high detection rate and a domain test suite with a high mutation score cover different failures. I did not run Infection on this toy domain; with 13 files it would prove nothing.

Limits, honestly

13 files and 12 hand-written mutants: this is a demonstration of a method, not a benchmark of the tools. Do not read the table as "phpat beats Deptrac".
The thresholds (an anemia share, five members per aggregate) are arbitrary.
The mutants are textual patches. Real violations are subtler, and generating them automatically, the way mutation tools do for code, is the interesting next step.
Everything ran on one machine (Windows, PHP 8.4). The runner (php bin/mutants.php, about three minutes) restores the sources afterwards.
The 2017 post's own limitation stands: no tool tells you that your aggregate boundaries are right. These checks keep a model from drifting; they do not design it.

References

Lukas Taake, "Static code analysis for Domain-Driven Design, part 1", 2017: https://www.ltaake.com/blog/2017/09/static-code-analysis-for-domain-driven-design-part-1/
Eric Evans, Domain-Driven Design (2003); Vaughn Vernon, Implementing Domain-Driven Design (2013).
Yue Jia and Mark Harman, "An Analysis and Survey of the Development of Mutation Testing", IEEE Transactions on Software Engineering, 2011.
Tools: PHPStan, Deptrac, phpat, PHP Arkitect, Infection.

I maintain a PostgreSQL search library, Fuzzphony, and the habit of asking "would a test notice if this were wrong?" came from there; I wrote about what a 95% mutation score still misses in the previous post. If you run something like this on a real codebase, I would like to hear which mutants your rules missed.

95% mutation score, and a review still found a cross-tenant leak: Fuzzphony 0.11

Szj — Thu, 05 Nov 2026 08:06:17 +0000

Last time I wrote about building search next to a database I couldn't touch. Fuzzphony was at v0.4 then. It is v0.11.1 now, and the post ended with a section called "What I haven't solved yet". So this one starts there.

The short version: a typo-tolerant, ranked search for a PostgreSQL database you may not be allowed to change (a sidecar table, pg_trgm, full-text search, no new infrastructure). The longer version is below, including the part I find more interesting than the features: a 95% mutation score did not stop three real bugs, and an independent review found them the week before the release.

What I said I hadn't solved

Short words matched the wrong thing. mouse matched monitor, because a flat trigram threshold is too generous for a five-letter word and too strict for a fifteen-letter one. Since 0.7 the tolerance grows with the length of the word, so mouse stays mouse, and hedphones still finds headphones.

Very common words lost their best match. The candidate window (candidate_limit, 2000 by default) is cut before ranking, so for a word that appears in half the catalogue the best hit could fall off the edge. 0.9.8 changed how candidates are chosen so the best match of a very common word is no longer lost above the limit. The same release added tolerance for swapped letters (recieve) and a zero-result rescue: when a search finds nothing, it retries the closest spelling and tells you it did (correctedTo).

Operations. Reindexing without a gap (a shadow table that is swapped in), Prometheus metrics with sample Grafana dashboards, synonyms from Solr/Elasticsearch files that can be swapped at runtime, and "did you mean" from a vocabulary table all landed between 0.5 and 0.7. The rest of the rough edges I listed then are in the changelog.

0.10: secure by default

The part of search libraries I trust least is the part that decides who may see what, so 0.10 was the breaking release that made the safe thing the default.

Without a token the caller is anonymous. A system caller has to say so:

// a console command, a cron job: explicitly the system
$hits = $fuzzphony->in('customers')->asSystem()->query('kovacs')->get();

// a web request: the ambient actor is whoever is logged in
$hits = $fuzzphony->in('customers')->forTenant($tenantId)->query('kovacs')->get();

There is one tenant rule: an actor of tenant A cannot ask for tenant B, unless the call is asSystem(). Fields can be granted to a role, and a search by a viewer who does not hold the grant must not change because of a field they cannot see. I call that hidden-field independence: ids, ranks, totals, facets and highlights are the same whatever the hidden fields contain. There are also two database roles (a worker and an admin) with --dump-grants so the search process never needs DDL rights, and code: true fields for invoice numbers and SKUs (INV-001-style values are matched exactly, not "fuzzily"). The public API went from 102 types to 77, so the surface you can rely on is smaller and written down.

0.11: several sources, several values, one row to render

Real systems have a customer table, a company table, and orders. 0.11 lets one index read all of them (a simplified version of the demo's site index):

fuzzphony:
  indexes:
    site:
      sources:
        person:
          query: "SELECT id, name AS title, email AS body, account_id AS account FROM erp_customer WHERE kind = 'person'"
          watch: { erp_customer: "SELECT :id" }
        order:
          query: "SELECT id, number AS title, note AS body, account_id AS account FROM erp_order"
          watch: { erp_order: "SELECT :id" }
      fields: { title: { weight: A, fuzzy: true }, body: C }
      filters: { account: int }
      tenant: account

A hit says which source it comes from ($hit->kind) and carries that source's own typed id. Each source has its own watch, so changing a row refreshes only the right document, and the doctor now warns when the source query reads a table no watch covers.

A customer has several addresses. Instead of a folded string_agg(...) column, a field can say where the values live:

city:
  weight: C
  fuzzy: true
  many: { from: address, key: customer_id, column: city, limit: 50 }

and the explanation tells you which address matched ("found in the address: Budapest"). The next release is going to rank by the best single value instead of the whole field; that is a design I would rather finish properly than rush.

And the thing every search page needs: a result row. with() returns columns of the hit's source row, so a page can be rendered and linked without loading entities:

$result = $fuzzphony->in('products')->query('mouse')->limit(10)->with('title', 'slug', 'price')->get();

foreach ($result->hits as $hit) {
    echo $hit->data['title'], ' ', $hit->data['price'];
}

It is opt-in, reads the current value (nothing extra is copied into the index), and a column behind a granted field is returned only to someone who holds the grant. Remember that last sentence; it comes back below.

The demo grew an ERP data set (about half a million rows: customers, companies, addresses, orders, order lines), an ERP page with separate and combined search boxes, a live demonstration of the sync (move an address to another city, watch which indexes refreshed), and a search box in the header that searches every index of the demo at once. With about seven indexes the engine answers in 40 to 170 ms.

How I know it works

The test suite has about 3,700 tests, PHPStan at max level, and coverage close to 100%. Coverage tells you which lines ran. Mutation testing tells you whether the tests would notice if a line were wrong: the tool changes the code a little (> becomes >=, && becomes ||, a line disappears) and runs the tests; a mutant that survives is a place where nothing checks the behaviour.

The numbers, from CI:

Run	Mutants	Covered-code score
First full run (September)	3,944	85%
After 0.8.1	5,989	96%
0.11.0 branch	about 11,900	95%

The last full run takes 1 hour 45 minutes on CI, so it always lags one step behind the code; I run it once per release and work with the result. Of the 486 survivors in 0.11 I killed the ones in the new code with focused tests (assert what the code must do, never a mirror of the code), and I sorted the rest into a few classes that cannot be killed because the mutant is equivalent:

a limit that the validator already guarantees (a replace "limited to 1" versus "limited to 2" when exactly one placeholder can exist),
a cast on an array key that PHP normalises anyway,
array_values() on a list that is only iterated,
a branch the code itself marks as unreachable.

It sounds boring, and it is, until you read the next section.

What a mutation score cannot see

Before tagging 0.11.0 I asked for an independent, adversarial review of everything new in src/ (about 2,700 added lines), with one instruction: try to break the two promises that matter, hidden-field independence and no tenant crossing. It found three real bugs, behind a 95% score and a green suite.

1. A hit of the wrong kind became someone else's row. In a multi-source index the hits are emp:1 and post:2. The helper that turned a result into ids dropped the kind, so loading the Emp entity from the result looked up [1, 2], and Emp 2 is a row of another tenant that did not match anything:

$result = $fuzzphony->in('site')->forTenant(1)->query('ada')->get();   // hits: emp:1, post:2
$result->ids();                                                         // [1, 2]  (the kind is gone)
$loader->load($result, Emp::class);                                     // loads Emp 1 and Emp 2 (tenant 2)

The fix uses only the hits whose source reads the requested class. I never would have written a test for it, because the single-source world, where ids are enough, was the only one I was thinking about.

2. with() leaked a granted column under another name. The grant check looked at the field name; returnable lists column names. A field pay reading the column salary and granted to ROLE_HR was refused when asked as with('pay'), and returned to everybody when asked as with('salary'). The check now follows the column.

3. The ORM sync refreshed only the first index of an entity. A second index of the same entity, or a multi-source index reading it, was never refreshed: deleted rows stayed findable, and a row moved to another tenant stayed in the old tenant's results.

None of these has a surviving mutant to point at. The code for each was covered, the lines ran, and the tests asserted what I had thought of. A mutation score finds the tests I forgot to write for code I wrote; it cannot find the requirement I forgot. Only someone (or something) with a different mental model can, and so I now treat an independent review as part of the release, next to the suite, not after it.

Other safety nets that earned their place:

A differential harness. For anything that touches ranking, a script runs 1,854 searches against the previous release and the new code and demands byte-identical results and statements, with the sequential-scan synchronisation switched off so timings are comparable.
CI jobs that are not the happy path. The tests run against several PostgreSQL versions, with the oldest allowed dependencies, and against the next Symfony. In this release the first CI run was red for three reasons my machine had not shown: a demo smoke job that did not seed the new tables, a NAN in an error message that PHP turned into a warning (and PHPUnit into a failure), and an old Doctrine whose stub returned null where the new one returned an array.

What's next

0.12 is ranking by the best value of a field with several values (with a per-search switch for "one value must hold all the words"), a first step to a smaller sidecar, and the remaining mutation gaps. After that, 1.0: a stable API and a backward-compatibility promise.

The library is on GitHub (er2es/fuzzphony), and the demo runs with one docker compose up. If you have a database you cannot change and a search box that disappoints your users, I would like to hear what breaks first.

The State of Mutation Testing (Infection) in the PHP Ecosystem: A Scientific and Practical Analysis

Szj — Sun, 11 Oct 2026 05:33:02 +0000

Abstract

For decades, Code Coverage has served as the primary quality assurance metric in the software engineering industry. However, this metric often provides a false sense of security: it merely proves that a specific line of code was executed during a test run, but it does not guarantee that the test contains relevant and rigorous assertions. Mutation Testing provides an exact solution to this anomaly, with the Infection framework becoming the de facto standard in the PHP ecosystem. This analysis examines the efficacy, exponential resource requirements, theoretical limitations, CI/CD applicability, and the Return on Investment (ROI) of the methodology in enterprise environments.

1. Theoretical Background and Methodology

The fundamental question of mutation testing—and a core paradox of quality assurance—is: "Who guards the guards?" In other words, what mechanism can validate the reliability of the test suite itself?

The Infection PHP framework operates through the dynamic manipulation of the Abstract Syntax Tree (AST). During execution, the program injects syntactically correct but semantically incorrect modifications (mutations) into the source code.

Typical mutation operators include:

Arithmetic mutations: Replacing the + operator with the - operator.
Relational mutations: Degrading a > (strictly greater than) condition to a >= (greater than or equal to) condition.
Return value and boolean mutations: Replacing return true with return false, or removing method calls entirely.

Each autonomously generated, modified version of the code is called a Mutant. Following generation, the system iteratively runs the existing test suite against the given mutant:

If the test fails, the mutant is considered Killed. This is the ideal scenario, proving that the test suite is sufficiently defensive.
If the test passes successfully, the mutant has Escaped the assertions. This clearly indicates that the test suite is blind to that specific change in the business logic.

From these results, the framework aggregates the MSI (Mutation Score Indicator), which represents the percentage of successfully killed mutants.

2. The Value Proposition (ROI)

Based on scientific research and industry experience, the integration of Infection results in a significant paradigm shift regarding software quality.

Empirical Measurement of Software Quality: A traditional 100% Line Coverage can be achieved even if the tests contain absolutely no assert statements. In contrast, the MSI metric cannot be manipulated. Mutation testing ruthlessly exposes unhandled edge cases, the over-preference for the "happy path," and the lack of robustness in the code.
Identification of Redundancy and "Dead Code": The methodology identifies overly complex control flows with surgical precision. If a mutant continuously survives tests within a complex branch, it most often indicates that the specific code block is unreachable based on business logic (dead code), or it is so redundant that it requires immediate refactoring.
Cultural and Developer Education: The methodology proactively shapes the test-writing culture of engineering teams. Engineers learn to write higher-quality, defensive code and more rigorous assertions, minimizing the ratio of superficial tests.

3. Technological Limitations and Critical Analysis

While the methodology is theoretically sound, its practical implementation—especially in large-scale enterprise environments—faces severe technological and resource constraints.

3.1. Combinatorial Explosion and Computational Overhead

The most significant obstacle to mutation testing is its exponential resource requirement. If a project has 1,000 tests and Infection generates 5,000 mutants, it theoretically requires the test suite to be executed 5,000 times.

The continuous rebuilding of the AST and the thousands of initializations of the test runner (PHPUnit/Pest) introduce extreme CPU and memory loads. A standard 2-minute Continuous Integration (CI) test run can easily balloon to 40-60 minutes with full-scale Infection application, which is incompatible with the fast feedback loops expected in modern Agile/DevOps pipelines.

3.2. The Equivalent Mutants Problem

Academic studies unanimously refer to the phenomenon of equivalent mutants as the deepest, still only partially solved challenge of mutation testing. These are syntactic transformations that do not mathematically or logically alter the final semantics of the code.

Example: An operator change made for optimization purposes in a loop's indexing creates a mutation, but the algorithm's output remains invariant.

Because these mutants naturally always survive the tests, they falsely degrade the MSI score. Developers can lose valuable work hours manually analyzing these false positives, leading to what is known as "Developer Fatigue."

3.3. Implementation Challenges in Legacy Systems

Introducing Infection into a monolithic PHP application with high technical debt and low (sub-50%) test coverage is counterproductive. The system will generate surviving mutants in the tens of thousands, creating unprocessable informational noise for the team. The methodology only provides true value in codebases that already possess dedicated, high coverage (ideally above 85%).

4. Modern Optimization Strategies (CI/CD Integration)

To ensure sustainable usage, the PHP community and framework maintainers have introduced innovative architectural solutions that allow mutation testing to be integrated into daily development cycles:

Multithreading: Modern PHP environments (e.g., via the pcntl extension) support the asynchronous, parallel processing of mutants. Fully utilizing available CPU cores (e.g., --threads=4) drastically reduces execution time.
Incremental Diff-Based Testing: This represents the greatest technological breakthrough. In modern CI pipelines, Infection does not scan the entire codebase; instead, it strictly limits mutant generation to the lines of code modified in the Pull Request or Git commit (--git-diff-lines). This technique reduces runtime from hours to mere seconds.
Baseline Architecture: Similar to static code analyzers (PHPStan, Psalm), Infection can save existing, historical surviving mutants into a reference file (baseline). Consequently, the CI process only fails if a developer attempts to integrate new, inadequately tested code into the system.

5. Conclusion and Architectural Recommendations

The application of mutation testing is not a universal silver bullet; its adoption requires a deliberate engineering decision.

Critically Recommended Application Areas:

Financial technologies (FinTech), payment gateways, and transactional systems.
High-risk healthcare and government software.
Widely used Open Source libraries (e.g., the Symfony and Doctrine ecosystems actively benefit from this level of scrutiny).
Isolated testing of the Core/Domain (business) layer in software built on strict Domain-Driven Design (DDD) principles.

Contraindicated Areas:

Rapid prototypes and applications in the MVP (Minimum Viable Product) phase.
Simple CRUD (Create, Read, Update, Delete) and administrative interfaces.
Thin API endpoints where the code exclusively performs database reads without complex logical transformations.

Final Verdict: The application of Infection in the PHP ecosystem represents the current State of the Art in software quality. Engineering teams willing to navigate the adoption curve and manage the increased CI/CD resource requirements will achieve a degree of mathematical and logical stability that is completely unattainable with traditional coverage metrics.

Bibliography and References

[1] DeMillo, R. A., Lipton, R. J., & Sayward, F. G. (1978). Hints on Test Data Selection: Help for the Practicing Programmer. IEEE Computer, 11(4), 34-41. (The foundational work laying the theoretical groundwork for mutation testing).
[2] Jia, Y., & Harman, M. (2010). An Analysis and Survey of the Development of Mutation Testing. IEEE Transactions on Software Engineering, 37(5), 649-678. (A comprehensive industry study on the adoption and efficacy of mutation testing).
[3] Offutt, A. J., & Pan, J. (1996). Detecting Equivalent Mutants and the Feasible Path Problem. Proceedings of the 11th Annual Conference on Computer Assurance (COMPASS '96). (Scientific analysis of the equivalent mutants phenomenon and the challenges of detecting them discussed in this article).
[4] Infection PHP Official Documentation. (2024). Infection - PHP Mutation Testing Framework. Available at: infection.github.io (Official reference for technical implementation details, Git Diff filtering, and Baseline functionality).

5 Angular Anti-Patterns You Need to Stop Using Immediately (and How to Fix Them in Angular 21)

Szj — Sun, 11 Oct 2026 04:58:00 +0000

Angular is a robust, enterprise-grade framework, but with great power comes great responsibility. Because Angular gives us so much freedom, it is incredibly easy to shoot ourselves in the foot, especially as the application starts to scale.

If your app feels sluggish, or if your components are becoming an unmaintainable mess, chances are you are falling victim to a few common bad habits.

Let's look at 5 of the most frequent Angular anti-patterns and how to refactor them using modern, clean code practices tailored for Angular 21.

1. Function Calls in Templates (The Performance Killer)

The Anti-pattern: Calling a component method directly in your HTML template for data binding.

<!-- [BAD]: This will execute on every single Change Detection cycle -->
<p>Total: {{ calculateTotal(cartItems) }}</p>
<div [class.active]="checkIfUserIsActive(user)"></div>

Why it is bad: Angular's Change Detection (CD) is aggressive by default. Every time anything happens (a click, a timer, an HTTP response), Angular checks the template for changes. If you bind a function in the template, Angular has to re-execute that function every single CD cycle to see if the return value changed. If calculateTotal involves heavy array manipulation, your app will freeze.

The Modern Solution:
Use Pure Pipes for transformations, or better yet, use Angular 21 Signals.

// [GOOD]: Using Angular 21 Signals
cartItems = signal<CartItem[]>([]);

// computed() caches the value and ONLY recalculates if cartItems changes!
total = computed(() => this.cartItems().reduce((acc, item) => acc + item.price, 0));

<!-- [GOOD]: Just binding to the computed signal -->
<p>Total: {{ total() }}</p>

2. Abandoned Subscriptions (The Memory Leak)

The Anti-pattern: Subscribing to an Observable but forgetting to unsubscribe when the component is destroyed.

// [BAD]: This subscription lives forever, even if the user navigates away.
ngOnInit() {
  this.userService.getUserData().subscribe(data => {
    this.userData = data;
  });
}

Why it is bad: When the Angular Router destroys this component, the subscription remains active in memory. This leads to memory leaks and ghost code executions in the background, causing weird UI bugs and crashing browsers.

The Modern Solution:
If you must use RxJS instead of Signals for a specific data stream, use the takeUntilDestroyed() operator. In modern Angular, you do not even need to implement ngOnDestroy for this.

// [GOOD]: Modern approach
import { takeUntilDestroyed } from '@angular/core/rxjs-interop';

export class UserComponent {
  constructor(private userService: UserService) {
    this.userService.getUserData()
      .pipe(takeUntilDestroyed()) // Automatically unsubscribes on destroy!
      .subscribe(data => this.userData = data);
  }
}

3. Nested Subscriptions (The Reactive "Callback Hell")

The Anti-pattern: Subscribing to an Observable inside another Observable's subscribe block.

// [BAD]: Hard to read, impossible to test, and prone to race conditions.
this.route.params.subscribe(params => {
  this.userService.getUser(params['id']).subscribe(user => {
    this.projectService.getProjects(user.organizationId).subscribe(projects => {
      this.projects = projects;
    });
  });
});

Why it is bad: It breaks the declarative nature of RxJS. More importantly, it creates race conditions. If the user clicks fast and triggers multiple ID changes, the HTTP responses might arrive out of order, rendering the wrong data on the screen.

The Modern Solution:
Leverage Higher-Order Mapping operators like switchMap, concatMap, or mergeMap.

// [GOOD]: Clean, linear, and handles race conditions safely.
this.projects$ = this.route.params.pipe(
  switchMap(params => this.userService.getUser(params['id'])),
  switchMap(user => this.projectService.getProjects(user.organizationId))
);

(Note: switchMap is perfect here because it cancels previous pending requests if a new ID is emitted).

4. "Fat" Components (The God Object)

The Anti-pattern: Stuffing business logic, direct HTTP calls, and complex state manipulation directly into the .ts file of your component.

Why it is bad: Your component becomes a monolith. It becomes untestable (because you have to mock 15 different dependencies) and impossible to reuse. UI components should only care about presenting data and catching user events.

The Modern Solution:
Adopt the Smart / Dumb (Presentational) Component Architecture using Standalone Components, and use a Facade or Service for logic.

Move your HTTP logic and state mutations into a dedicated Service, keeping your component clean:

// [GOOD]: The component just binds to the facade service.
@Component({
  standalone: true,
  // ...
})
export class CartComponent {
  // Injecting the service using the modern inject() function
  private cartFacade = inject(CartFacadeService);

  cartItems = this.cartFacade.items; // This is a Signal exposed by the service

  onRemoveItem(id: string) {
    this.cartFacade.removeItem(id); // The service handles the actual logic and API call
  }
}

5. The Desperate `ChangeDetectorRef` Hack

The Anti-pattern: Injecting ChangeDetectorRef and throwing cdr.detectChanges() or wrapping code in setTimeout(() => {}, 0) just to force the UI to update.

// [BAD]: Forcing Angular to update because the data flow is broken.
updateUser() {
  this.user.name = 'John';
  this.cdr.detectChanges(); // Please update the UI, I am begging you!
}

Why it is bad: If you find yourself using this, it means you have lost control of your state management or you are mutating data directly instead of creating new references. It is treating the symptom instead of curing the disease.

The Modern Solution:
Embrace Zoneless Angular and Immutability.

Angular 21 fully supports going Zoneless (provideZonelessChangeDetection()). In a Zoneless environment, the framework relies entirely on Signals and built-in reactive primitives to know when to update the DOM, eliminating the need for Zone.js overhead or manual cdr.detectChanges() hacks.

// [GOOD]: Treat data as immutable and use Signals for automatic UI updates
@Component({
  standalone: true,
  // ChangeDetectionStrategy.OnPush is also recommended if you are not fully zoneless yet
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class UserComponent {
  user = signal({ name: 'Jane', age: 30 });

  updateUser() {
    // Updating the signal automatically schedules a highly optimized UI update
    this.user.update(u => ({ ...u, name: 'John' })); 
  }
}

Wrapping Up

Angular has heavily shifted towards a reactive, Signal-driven, and Zoneless future. By dropping these 5 anti-patterns and embracing the paradigms of Angular 21, you will immediately notice improvements in your app's Lighthouse scores, memory footprint, and overall developer experience.

Over to you: Which of these anti-patterns do you see most often in legacy codebases? Are there any others you would add to this list? Let me know in the comments!

PostgreSQL 19 WAIT FOR LSN from PHP: read-your-writes on a replica, and four ways it bites" published: false

Szj — Wed, 30 Sep 2026 18:26:12 +0000

You add a read replica. A user saves a form, gets redirected, and the next page shows the old data. The write went to the primary, the read went to the replica, and the replica hadn't caught up yet.

PostgreSQL 19 adds a built-in answer: the WAIT command. You give it the WAL position (LSN) of your write, and the replica blocks until it has replayed that far. I tried it from PHP on PostgreSQL 19 Beta 4, and found a few things worth knowing before you ship it.

Note: PostgreSQL 19 was at Beta 4 when I wrote this. Check the final release notes, as details may still change.

The problem, measured

Setup: one primary and one asynchronous streaming standby on the same machine, PHP 8.5.10 with PDO. After each INSERT on the primary I read the row back from the replica immediately.

5000 of 5000 reads were stale. Not most of them. All of them. The read arrives about 60 µs after the commit, and the row takes roughly 300 µs to get replayed on the replica. Under write load (pgbench with 4 clients on the primary) it was 1496 of 1500.

The fix

WAIT FOR LSN '0/0306EE20' WITH (TIMEOUT '50ms', NO_THROW);
-- returns one row: success | timeout | not in recovery

The flow: write on the primary, grab the current LSN, run WAIT on the replica, then read from the replica.

final class ReadYourWrites
{
    public function __construct(
        private PDO $primary,
        private PDO $replica,
        private int $timeoutMs = 50,
    ) {}

    /** Call right after the write has committed on the primary (synchronous_commit = on). */
    public function commitLsn(): string
    {
        return $this->primary->query('SELECT pg_current_wal_flush_lsn()')->fetchColumn();
    }

    /** Returns the connection that is safe to read from. Never call inside an open transaction. */
    public function readerFor(?string $lsn): PDO
    {
        if ($lsn === null) {
            return $this->replica;
        }
        if (!preg_match('~^[0-9A-F]+/[0-9A-F]+$~', $lsn)) {
            throw new InvalidArgumentException('Not a valid LSN');
        }
        $status = $this->replica
            ->query("WAIT FOR LSN '$lsn' WITH (TIMEOUT '{$this->timeoutMs}ms', NO_THROW)")
            ->fetchColumn();

        return $status === 'success' ? $this->replica : $this->primary;
    }
}

Result on 5000 writes: 0 stale reads, with a median wait of 315 µs on an idle standby and 1.2 ms under write load. If the replica can't catch up in time, the code falls back to the primary, which is always correct.

The LSN has to travel with the user between requests. Keep it in the session, and read from the replica only after WAIT succeeds.

Scenario	Stale reads without WAIT	Stale reads with WAIT	WAIT median
Idle standby	5000 / 5000	0 / 5000	315 µs
Write load	1496 / 1500	0 / 1500	1.2 ms

All numbers come from a single vCPU running everything (primary, standby, PHP, pgbench), so absolute latencies are inflated and a real network adds a round trip. Treat the ratios, not the microseconds, as the point.

Gotcha 1: you can't bind the LSN

WAIT is a utility command, so PostgreSQL doesn't accept parameters in it. With PDO's default native prepared statements:

$stmt = $replica->prepare('WAIT FOR LSN :lsn');
$stmt->execute(['lsn' => $lsn]);
// SQLSTATE[42601]: syntax error at or near "$1"

It only works with ATTR_EMULATE_PREPARES = true. The safe option is to validate the string with a strict regex (as in the class above) and interpolate it. An LSN is just hex, a slash and hex.

Gotcha 2: it must be the first thing in a transaction

The docs say WAIT can't run while you hold a snapshot or locks. In practice:

$replica->beginTransaction();
$replica->query('SELECT count(*) FROM t');
$replica->query("WAIT FOR LSN '$lsn'");
// ERROR: cannot wait for a standby LSN while holding locks

The same applies after the first query in a REPEATABLE READ transaction (WAIT cannot be executed while the current transaction holds a snapshot). A plain SET LOCAL before it is fine.

Two details cost me time:

An error inside a transaction aborts it (SQLSTATE 25P02), so call WAIT before beginTransaction().
If the target LSN is already reached, WAIT returns immediately even after a query. The restriction only triggers when it would actually have to wait. So your tests can pass on an idle replica and fail in production.

It also can't run inside a DO block or function (WAIT can only be executed as a top-level statement).

Gotcha 3: the docs' LSN function can hang

The documentation example takes the LSN with pg_current_wal_insert_lsn(). In my idle test, 5 out of 5000 waits timed out. Every one of those LSNs had the same page offset: 24 bytes, which is the size of a WAL page header.

0/0322A018   0/03240018   0/03268018   0/032C8018   0/032DE018

My explanation (an inference, not something I checked in the source): the commit record ended exactly at a WAL page boundary, and the insert pointer was reported after the new page's header. The replica has replayed everything that exists, but the target sits 24 bytes past the last real record, so WAIT blocks until more WAL arrives. On an idle system that can be a long time.

With the default synchronous_commit = on, pg_current_wal_flush_lsn() does not have this problem: 0 timeouts in 5000, and it was also slightly faster. Either way, use TIMEOUT and NO_THROW, check the status, and fall back to the primary. Never ignore the returned status.

Gotcha 4: synchronous_commit = off changes everything

If your app uses asynchronous commit, the flush LSN can be behind your commit record:

Primary session with `synchronous_commit = off`	Result
`flush_lsn`, then WAIT	`success` in 48 µs, but 300 / 300 reads were stale
`insert_lsn`, then WAIT	correct, but median wait 201 ms

WAIT dutifully reports success for a position the replica really did reach. It just isn't your write. The insert LSN is correct here, but you pay roughly one wal_writer_delay (200 ms by default) per wait, and 8 of 300 still hit my 300 ms timeout.

So: flush LSN if you use synchronous commit, insert LSN plus the fallback if you don't.

Symfony and Doctrine

Nothing here is tied to PDO. With DBAL, run the same WAIT through executeQuery() on the replica connection, before opening a transaction. One natural place to capture the LSN is a listener that runs after a flush on the primary connection and stores the result in the session. I've only tested the plain PDO version above, so treat that as a design sketch.

Takeaways

Read-after-write against an async replica is broken by default: 5000/5000 stale reads in my test.
WAIT FOR LSN fixes it cheaply: about 0.3 ms idle, about 1.2 ms under write load on my setup.
Always pass TIMEOUT and NO_THROW, check the status, and fall back to the primary.
Validate the LSN yourself, because you can't bind it.
Call it before opening a transaction.
Pick the LSN function to match your synchronous_commit setting.

I ran into this while working on search and read-heavy PostgreSQL workloads for PHP, including Fuzzphony. If you have a real multi-machine setup, I'd love to see your numbers in the comments.

grapheme_levenshtein() in PHP 8.5: what the docs don't tell you

Szj — Wed, 30 Sep 2026 17:23:11 +0000

PHP's levenshtein() has always counted bytes. For English that's invisible. For Hungarian, Polish, Czech, or anything with accents, it quietly lies:

levenshtein('szőke', 'szoke'); // 2, but it's one edit

The ő is two bytes in UTF-8 (C5 91), so the function sees two edits. PHP 8.5 finally adds grapheme_levenshtein(), which counts user-perceived characters instead. Every article I found about it explains the syntax. None of them measured it, so I did.

Setup

PHP 8.5.10 (CLI, built from source), ICU 74.2, default settings, no JIT
Synthetic Hungarian-style words (with sz, cs, ő, ű, ...), each compared with a copy containing one random edit
20,000 pairs per length, best of 3 rounds, nanoseconds per comparison
Single vCPU sandbox: absolute numbers will differ on your machine, the ratios are what matter.

What it fixes

Pair	`levenshtein()`	code points	`grapheme_levenshtein()`
`szőke` vs `szoke`	2	1	1
`Kovács` vs `Kovacs`	2	1	1
`ő` vs `ö`	2	1	1
`é` (NFC) vs `é` (NFD)	3	2	0
👩‍💻 vs 👩	7	2	1

The NFC/NFD row is the real win. The same visible é can be stored as one code point or two (e + combining accent), depending on where the data came from. The byte version reports 3 edits between two strings that look identical. The grapheme version correctly reports 0.

What it costs

Length	`levenshtein()`	`grapheme_levenshtein()`	with `locale='hu'`	userland, code points
8 chars	0.22 µs	3.3 µs	4.0 µs	3.8 µs
24 chars	1.3 µs	14.1 µs	17.6 µs	29.2 µs
64 chars	6.4 µs	76.9 µs	98.2 µs	196.1 µs

Three things stand out:

It is 11-15x slower than the byte version. Correctness isn't free: the function segments both strings into grapheme clusters and compares them through ICU.
It beats a userland implementation by about 1.2x on short strings and 2-2.6x on longer ones. If you were using a pure PHP multibyte Levenshtein, switching is a clear win.
The $locale parameter adds 23-28% on top.

The manual documents the complexity as O(m*n). In practice that means you should not run it over a whole table: at 24 characters, 1M rows is roughly 14 seconds of CPU per query, versus about 1.3 seconds for the byte version.

Two surprises

Invisible characters can compare as equal. In my tests on 8.5.10:

grapheme_levenshtein("\x01", "\x02");          // 0
grapheme_levenshtein("\u{200B}", "\u{200C}");  // 0
grapheme_levenshtein("\x01", "");              // 1

Two different control or zero-width characters are treated as identical to each other, yet each one differs from an empty string. The equality check is a collation comparison, and ICU collation ignores some characters completely. Mid-word cases behave less predictably ("a\u{200B}b" vs "a\u{200C}b" gave 1, while "a\x01b" vs "a\x02b" gave 0). A soft hyphen (U+00AD) is not ignored and costs one edit. This matches a recently reported php-src issue, so check the current status before relying on either behavior.

For search this is mostly harmless, but if you use the distance for deduplication or validation, strip control and format characters first.

The locale parameter changed nothing in my tests. I compared hu against en on every case above, including cs vs c and sz vs s, where you might hope for Hungarian digraph awareness. The results were identical in all cases. It only added the 23-28% cost. I'm not claiming it never matters (I can't rule out effects on other scripts or case-insensitive comparisons), but for Hungarian names it bought me nothing.

Also note that the comparison is case-sensitive: Kovács vs kovács is 1.

So how should you use it?

Don't scan with it, re-rank with it. Let the database produce candidates cheaply and let PHP do the precise scoring on a handful of rows.

-- PostgreSQL + pg_trgm: fast candidate generation
SELECT name
FROM people
WHERE name % :query
ORDER BY similarity(name, :query) DESC
LIMIT 50;

function clean(string $s): string
{
    // strip control/format characters, then lowercase
    return mb_strtolower(preg_replace('/[\p{Cc}\p{Cf}]/u', '', $s));
}

function rerank(string $query, array $candidates, int $maxDistance = 2): array
{
    $q = clean($query);
    $scored = [];
    foreach ($candidates as $name) {
        $d = grapheme_levenshtein($q, clean($name));
        if ($d !== false && $d <= $maxDistance) {
            $scored[$name] = $d;
        }
    }
    asort($scored);
    return $scored;
}

rerank('Szoke', ['Szőke', 'Szűcs', 'Szabó', 'SZOKE']);
// ['SZOKE' => 0, 'Szőke' => 1]

Re-ranking 50 candidates of around 24 characters costs about 0.7 ms (50 x 14 µs), which is nothing next to the query itself. That's the sweet spot: the accuracy of a grapheme-aware distance at a cost you never notice.

Takeaways

Use grapheme_levenshtein() over levenshtein() whenever your data has accents or mixed Unicode normalization.
Expect ~12x the cost of the byte version, and never run it over a full table.
Normalize case and strip invisible characters yourself.
Measure before you reach for $locale.

I ran into all of this while building Fuzzphony, a PostgreSQL-native search library for PHP and Symfony. If you have your own numbers from a different machine or dataset, I'd love to see them in the comments.

I couldn't touch the database, so I built search next to it

Szj — Mon, 28 Sep 2026 18:40:07 +0000

A production system I work on needed a search box that forgives people. They type kavefozo and expect Kávéfőző. They type hedphones and expect headphones.

The constraints were the interesting part:

The schema could not change. No new columns, no generated columns, no migrations on tables that weren't ours.
No new infrastructure. No Elasticsearch, no Meilisearch, no extra service to run, sync, back up and secure.

So search had to happen inside the database that was already there. PostgreSQL turned out to have almost every piece needed. Wiring those pieces together properly was the hard part, and that wiring became an open-source library: Fuzzphony.

Fuzzphony is at v0.4 and still in active development. The core works and is heavily tested, but the API can change before 1.0, and there are rough edges I'll be upfront about at the end.

This post covers the design, the bug that taught me the most, and what I still haven't solved.

What `LIKE '%…%'` gets wrong

Most search boxes start here:

SELECT * FROM product WHERE name ILIKE '%' || :q || '%' LIMIT 20;

It misses typos (hedphones), accents (creme vs crème) and word forms (drills vs drill). It can't exclude a word, it doesn't rank, and when it misses, it reads the whole table to return nothing.

Postgres ships three tools for exactly these problems:

Full-text search (tsvector, tsquery, ts_rank_cd): stemming for 28 languages, field weights A to D, relevance ranking.
unaccent: folds Kávéfőző into Kavefozo.
pg_trgm: trigram similarity, which is what lets wireles match wireless.

None of them is new. The work is in making them behave together, stay in sync with your data, and be safe to point at user input.

The sidecar table

Since your tables are off-limits, the index lives in its own table next to them.

For every index, Fuzzphony keeps a table such as fuzzphony_products with:

a weighted tsvector for full-text search, on a GIN index,
a normalised, unaccented text column for typo tolerance, on a GIN trigram index,
typed filter columns on btree indexes, so where('price', '<=', 20_000) never has to touch your table,
the inputs for ranking: a boost column (popularity, say) and a recency column.

The source can be a single table or any SELECT, joins included. With schema: fuzzphony set, the sidecar tables, the queue and the helper functions all live in their own schema, and dropping an index is one command.

To be precise about "off-limits": no column is ever added, but in the default queue mode and in trigger mode Fuzzphony does attach triggers to the tables it watches. That's how it sees writes from raw SQL, imports and other applications. If even a trigger is too much, the orm and manual modes need none.

The cost of the design is obvious: there is now a second copy of the searchable data, and it has to stay in sync.

Keeping it in sync without hurting writes

There are four sync modes:

Mode	How	When
`queue` (default)	triggers enqueue ids, `fuzzphony:worker` refreshes in batches	most apps; writes stay fast
`trigger`	triggers refresh inside the writing transaction	you need read-your-writes
`orm`	a Doctrine listener refreshes after `flush()`	triggers are not allowed at all
`manual`	nothing automatic	batch imports, read-only data

Three details made the trigger-based modes usable on real tables.

Statement-level triggers with transition tables. A row-level trigger on an UPDATE brand SET … that touches 100 000 rows fires 100 000 times. A statement-level trigger fires once and sees every changed row through a transition table, so queuing the affected products becomes a single set-based statement. In simplified form (not the exact generated SQL):

CREATE TRIGGER brand_sync
AFTER UPDATE ON brand
REFERENCING NEW TABLE AS changed
FOR EACH STATEMENT EXECUTE FUNCTION queue_products_of_changed_brands();

-- inside the function, roughly:
INSERT INTO sync_queue (index_name, doc_id)
SELECT 'products', p.id
FROM changed b
JOIN product p ON p.brand_id = b.id;

Only refresh when something relevant changed. An UPDATE product SET last_viewed_at = now() should not reindex anything. For the index's own table, Fuzzphony checks whether a mapped column actually changed. For joined tables you opt in with columns: ['name'], because a library cannot guess which of a joined table's columns matter to you.

TRUNCATE is not a delete. It fires no DELETE triggers, so early versions left stale documents in the index after a TRUNCATE, and not even a full reindex removed them. I found that one late. Now every watched table also gets an AFTER TRUNCATE trigger, and a full reindex prunes documents whose rows no longer exist.

The worker takes a batch with DELETE … FOR UPDATE SKIP LOCKED and refreshes it in the same statement, so a failed refresh rolls the dequeue back and no id is lost, and several workers can run side by side. If you'd rather not run a long-lived process, fuzzphony:worker --once from cron works too.

What happens to a query

From the application side, a search looks like this:

$result = $fuzzphony->in(Product::class)
    ->query('wireles mouse -cable')          // a typo and an exclusion
    ->where('price', '<=', 20_000)
    ->where('in_stock', true)
    ->highlight('name')
    ->get();

foreach ($result as $hit) {
    echo $hit->id, ' ', $hit->score, ' ', $hit->highlights['name'];   // "<mark>Wireless</mark> mouse"
}

Behind that call, the query goes through a few stages:

A few decisions in there are worth explaining.

User input never throws. Unbalanced quotes, stray operators and absurdly long input are repaired and reported in $result->warnings, and $result->interpretedAs shows how the query was understood. Developer mistakes are the opposite: they fail loudly, with a hint. Index "products" has no filter "prise". Did you mean "price"?

Exact first, typo tolerance as a fallback. Trigram matching is slower and noisier than full-text matching, so by default it only runs when exact matching finds fewer than fallback_below hits.

Typo tolerance is per word. The first version compared the whole query string against the fuzzy fields, so one long common word could satisfy it on its own. On the demo catalogue, wireles mice returned 20 000 products (chairs, drills, kettles), of which 1 666 were mice. Now every word has to match on its own, exactly or by trigram similarity, inside the query's real AND / OR / NOT structure. The same query returns exactly the 1 666 wireless mice.

An empty result gets one more try. If a query of two or more words finds nothing, each word is checked on its own, the words that match nothing are dropped, and the search runs again with a warning saying which words were ignored. wireless mouse aluminum returns the wireless mice instead of an empty page.

Ranking is explainable. The score is a plain formula:

relevance = text  × ts_rank_cd(weights A..D)
          + fuzzy × word_similarity(query, fuzzy fields)

score     = relevance
          + exact_bonus + prefix_bonus
          + boost   × boost column
          + recency × 2^(−age / half_life)

min_score applies to relevance only, so a popularity boost can reorder relevant hits but can never pull an irrelevant one into the results. Every hit carries a score breakdown, so "why is this first?" always has an answer.

The bug that taught me the most

A German test query, Tasche für Laptop, did not find a product called Laptop Tasche. In the French catalogue, searching for à alone matched 13 products. Hungarian és misbehaved the same way.

A text search configuration sends every token through a list of dictionaries, in order. Mine ran unaccent before the Snowball stemmer. The stemmer's German stop-word list contains für, but by the time the token reached it, it had become fur, which is not a stop word. So für was indexed as an ordinary word, and every query containing it had to match it.

The fix was to drop stop words before anything else touches the token, with a stop-word dictionary built from the language's own list. In simplified form:

CREATE TEXT SEARCH DICTIONARY fuzzphony_german_stop (
    TEMPLATE = simple, STOPWORDS = german, ACCEPT = false
);

CREATE TEXT SEARCH CONFIGURATION fuzzphony_german (COPY = german);

ALTER TEXT SEARCH CONFIGURATION fuzzphony_german
    ALTER MAPPING FOR asciiword, word, asciihword, hword, hword_asciipart, hword_part
    WITH fuzzphony_german_stop, unaccent, german_stem;

With ACCEPT = false, the stop dictionary discards stop words and passes everything else on to the next dictionary.

Two things came out of this besides the fix. fuzzphony:doctor now reports a configuration that still keeps accented stop words. And the demo got a Languages page that searches small catalogues in English, German, French, Spanish and Hungarian, and shows the lexeme Postgres produced for every query word. I would have caught this bug on day one if that page had existed earlier.

The numbers, with the caveats

A sample run on 200 000 products, PostgreSQL 16, a small cloud VM, 20 results per query:

Query	ILIKE (warm)	ILIKE hits	Fuzzphony (warm)	Fuzzphony hits
`wireless`	0.6 ms	20, unranked	11.1 ms	20 of 2000+, ranked
`creme`	251.6 ms	0	10.4 ms	20 of 2000+
`hedphones`	252.6 ms	0	20.7 ms	20 of 2000+
`drills`	257.1 ms	0	10.6 ms	20 of 2000+
`"noise cancelling" -headphones`	0.5 ms	20, wrong	23.2 ms	20 of 2000+

Read this carefully, because a benchmark against ILIKE is easy to make look good:

On plain words, ILIKE is much faster. LIMIT 20 without an ORDER BY just returns the first 20 rows the scan happens to hit. Fast, but not the best 20.
The ILIKE baseline has no trigram index, which is why its misses are full table scans. A gin_trgm_ops index would make those rows fast. It would not make them correct: ILIKE '%hedphones%' finds nothing no matter how it is indexed.
ILIKE has no concept of exclusion, so on the last row it silently ignores -headphones.

Run the numbers on your own data before believing anyone's benchmark, including this one. The benchmark script is in the repository, and CI runs it on every push.

When not to use it

Fuzzphony is not the right tool if you need hundreds of millions of documents or thousands of searches per second on one index, analytics-style aggregations, semantic or vector search (look at pgvector or a dedicated engine), or a database other than PostgreSQL.

It fits best where the database is not yours to change (a legacy system, an ERP, tables another team owns), where you are replacing LIKE in admin panels and back offices, or where the data has to stay in the database for compliance reasons.

What I haven't solved yet

Two things are genuinely open, and I'd like opinions on both.

Typo tolerance is too lenient on short words. At the default similarity threshold, mouse also matches monitor: short words have few trigrams, so a single shared one weighs a lot. The plan is length-aware thresholds, probably with trigrams only generating candidates from a vocabulary table and an edit-distance check deciding. How do you tune pg_trgm for short words?

Ranking of very frequent words. A GIN index can find matches but can't return them in relevance order, so for a word that matches tens of thousands of documents, Fuzzphony ranks the first candidate_limit (2000 by default) that the index returns. That's not necessarily the best 2000. For most back-office searches this doesn't show, but it's the real ceiling of doing search inside Postgres, and I'd rather say so than hide it behind "approximate ordering".

Rough edges I'm working on before 1.0

Writing the docs for v0.4 surfaced a few things I'd design differently, so they're on the list:

Trigger privileges. The sync functions run with the privileges of whoever writes the row. In a shared database, every role that writes to a watched table therefore needs grants on Fuzzphony's queue, or its writes fail. Moving the enqueue step into a SECURITY DEFINER function removes that coupling.
A batch that always fails. A refresh that fails deterministically (a document over Postgres' ~1 MB tsvector limit, for example) is rolled back and retried forever, which blocks the queue behind it. It needs a dead-letter path.
Pruning as a default. A full reindex removes documents whose rows it can't see. If the reindexing role sees fewer rows than the application (row-level security, a different search_path), that removes real documents. It should stop and ask above a threshold.
Field scoping leaks into typo tolerance. name:sony can return Sony-brand products, because the fuzzy fields share one trigram column. Per-field columns are planned for 0.5.

None of these show up in a single-app setup with one database role, which is how most people will try it. But they're exactly what bites in the environments Fuzzphony is aimed at, so they come before new features.

Try it

composer require fuzzphony/fuzzphony

Or run the demo, a full Symfony app on a seeded catalogue, with ILIKE and Fuzzphony side by side, a ranking playground with sliders, and a configuration wizard:

git clone https://github.com/er2es/fuzzphony
cd fuzzphony/demo && docker compose up --build    # http://localhost:8000

It requires PHP 8.4+ and PostgreSQL 15+, and is tested on Symfony 7.4 and 8.0 against PostgreSQL 15 to 18. The current release is v0.4 and development is ongoing: breaking changes can still happen before 1.0, and each one is listed in the CHANGELOG with upgrade steps in UPGRADE.md.

I built this with a lot of help from Claude Code. The design decisions are written down as ADRs in the repository, and the heavy testing (PHPStan at max level, 100% line coverage, mutation testing) is partly because of that: when you didn't type every line yourself, tests are how you know what the code actually does.

Feedback is very welcome, in the comments or as a GitHub issue, especially on the two open problems above. If the library looks useful, a star on GitHub helps other people find it.

DEV Community: Szj

Your architecture rules are code too: mutation-testing a DDD ruleset in PHP 8.4

The eight rules, then and now

Rule 2 first, because PHP does half of it

Rules 1 and 4: where only a custom rule helps

Rules 7 and 8: layers, with two tools that disagree

Rules 3 and 5: a number you choose

The question the rules cannot answer about themselves

What the table says

Limits, honestly

References

95% mutation score, and a review still found a cross-tenant leak: Fuzzphony 0.11

What I said I hadn't solved

0.10: secure by default

0.11: several sources, several values, one row to render

How I know it works

What a mutation score cannot see

What's next

The State of Mutation Testing (Infection) in the PHP Ecosystem: A Scientific and Practical Analysis

Abstract

1. Theoretical Background and Methodology

2. The Value Proposition (ROI)

3. Technological Limitations and Critical Analysis

3.1. Combinatorial Explosion and Computational Overhead

3.2. The Equivalent Mutants Problem

3.3. Implementation Challenges in Legacy Systems

4. Modern Optimization Strategies (CI/CD Integration)

5. Conclusion and Architectural Recommendations

Bibliography and References

5 Angular Anti-Patterns You Need to Stop Using Immediately (and How to Fix Them in Angular 21)

1. Function Calls in Templates (The Performance Killer)

2. Abandoned Subscriptions (The Memory Leak)

3. Nested Subscriptions (The Reactive "Callback Hell")

4. "Fat" Components (The God Object)

5. The Desperate ChangeDetectorRef Hack

Wrapping Up

PostgreSQL 19 WAIT FOR LSN from PHP: read-your-writes on a replica, and four ways it bites" published: false

The problem, measured

The fix

Gotcha 1: you can't bind the LSN

Gotcha 2: it must be the first thing in a transaction

Gotcha 3: the docs' LSN function can hang

Gotcha 4: synchronous_commit = off changes everything

Symfony and Doctrine

Takeaways

grapheme_levenshtein() in PHP 8.5: what the docs don't tell you

Setup

What it fixes

What it costs

Two surprises

So how should you use it?

Takeaways

I couldn't touch the database, so I built search next to it

What LIKE '%…%' gets wrong

The sidecar table

Keeping it in sync without hurting writes

What happens to a query

The bug that taught me the most

The numbers, with the caveats

When not to use it

What I haven't solved yet

Rough edges I'm working on before 1.0

Try it

5. The Desperate `ChangeDetectorRef` Hack

What `LIKE '%…%'` gets wrong