I expected a toy project, but it is a usable library, which required a lot of work. Good job on delivering. A few comments:
After reading "composer.json", I thought that the tests used a custom framework. I'm glad the project does not suffer from NIH syndrome, but the dev dependency on PHPUnit should be declared.
There should a warning that it's only meant for some Western Latin languages. The normalization of the input is built on a character table for a handful of cases. That's not enough for some Latin languages, e.g. Turkish. And any input with Cyrillic, Arabic, CJK and so on, will be ignored.
There is no Unicode normalization or cleanup. Real-life input have many corner cases, e.g. diacritics next to the characters, or invisible characters inside a word to prevent hyphenation. Unless I'm mistaken, this engine would treat the NFD form "fête" as "fe te", instead of the expected "fete", which the NFKD form "fête" produces. I suggest using ext-intl for Unicode normalization, at least as an option.
Lastly, I can't think of a use case for this library. I've always had access to some external service (MySQL, Postgresql, Manticore Search, Solr, etc.) or to a PHP extension for a local Sqlite with FTS. Even for hobby projects, I haven't deployed to a shared hosting for more than two decades.
Thank you for the detailed feedback, it's genuinely valuable.
You're right on all technical points : PHPUnit missing from dev dependencies is an oversight I'll fix, and the Unicode limitations are real and should be clearly documented. The NFD/NFKD case is a good catch.
On the use case: fair point. My motivation came from testing MySQL and SQLite full-text search on a shared OVH hosting : the performance with filters was consistently disappointing. That's the itch this scratches. I understand it doesn't match your experience, and that's perfectly legitimate.
I would actually reconsider adding phpunit as a dev dependency. It is a tool that runs independently from your project. Therefore it should not live in composer. I would recommend declaring the phar dependency with phive.
> I would recommend declaring the phar dependency with phive
+1. This eliminates a whole class of bugs in which you declared phpunit as a dev dependency but end up using a class that it brought in without declaring as a regular dependency. Without an external linter, you can’t really catch that until your production code doesn’t bring the class in and throws a fatal error.
2. That doesn’t apply to PHPUnit specifically, but if you, for example, import PHP-cs-fixer as dev dependency, it will bring symfony/console, and if you rely on that on your own code without importing it on composer.json as a regular dependency, the class will be missing when you composer install for production.
Great tool. Does it work with german umlaut (äöü)?
I find it very useful because shared hosting is still big for me. I use ultra cheap shared hosting for nearly everything. No Server maintainance and no funky serverless stuff
I expected a toy project, but it is a usable library, which required a lot of work. Good job on delivering. A few comments:
After reading "composer.json", I thought that the tests used a custom framework. I'm glad the project does not suffer from NIH syndrome, but the dev dependency on PHPUnit should be declared.
There should a warning that it's only meant for some Western Latin languages. The normalization of the input is built on a character table for a handful of cases. That's not enough for some Latin languages, e.g. Turkish. And any input with Cyrillic, Arabic, CJK and so on, will be ignored.
There is no Unicode normalization or cleanup. Real-life input have many corner cases, e.g. diacritics next to the characters, or invisible characters inside a word to prevent hyphenation. Unless I'm mistaken, this engine would treat the NFD form "fête" as "fe te", instead of the expected "fete", which the NFKD form "fête" produces. I suggest using ext-intl for Unicode normalization, at least as an option.
Lastly, I can't think of a use case for this library. I've always had access to some external service (MySQL, Postgresql, Manticore Search, Solr, etc.) or to a PHP extension for a local Sqlite with FTS. Even for hobby projects, I haven't deployed to a shared hosting for more than two decades.
Thank you for the detailed feedback, it's genuinely valuable.
You're right on all technical points : PHPUnit missing from dev dependencies is an oversight I'll fix, and the Unicode limitations are real and should be clearly documented. The NFD/NFKD case is a good catch.
On the use case: fair point. My motivation came from testing MySQL and SQLite full-text search on a shared OVH hosting : the performance with filters was consistently disappointing. That's the itch this scratches. I understand it doesn't match your experience, and that's perfectly legitimate.
I would actually reconsider adding phpunit as a dev dependency. It is a tool that runs independently from your project. Therefore it should not live in composer. I would recommend declaring the phar dependency with phive.
https://docs.phpunit.de/en/12.5/installation.html#phar-or-co...
I find this project very impressive and have bookmarked it for potential use in future projects. Thank you for making this.
> I would recommend declaring the phar dependency with phive
+1. This eliminates a whole class of bugs in which you declared phpunit as a dev dependency but end up using a class that it brought in without declaring as a regular dependency. Without an external linter, you can’t really catch that until your production code doesn’t bring the class in and throws a fatal error.
1. Just add phpcsfixer and phpstan like any sane project
2. If you use phpunit class in prod code, you deserve to get a fatal error
1. Both tools will not catch it, you need something like https://github.com/maglnet/ComposerRequireChecker
2. That doesn’t apply to PHPUnit specifically, but if you, for example, import PHP-cs-fixer as dev dependency, it will bring symfony/console, and if you rely on that on your own code without importing it on composer.json as a regular dependency, the class will be missing when you composer install for production.
Do you have comparative benchmarks on the filter performance? I'm particularly interested in the SQLite FTS case.
Great tool. Does it work with german umlaut (äöü)? I find it very useful because shared hosting is still big for me. I use ultra cheap shared hosting for nearly everything. No Server maintainance and no funky serverless stuff
Great start! This bridge between LIKE and a full-blown engine is exactly what's needed for the PHP long-tail.
We've been using https://github.com/loupe-php/loupe, works quite well for small-to-medium single-instance apps.
Zend used to maintain a PHP port of Lucene 15 years ago that I used, but not sure what happened to it.
Yes, Zend_Search_Lucene was dropped from Zend Framework 2 and never officially maintained for modern PHP. There's a community fork.
Any idea if it's any good? I used the old Lucene implementation ages ago and thought it was OK, though wasn't using it in a big way.
This is super cool! Thank you!
code looks pretty clean. is small and compact, decent benchmarks. might want to consider using an autoloader for classes.
The PSR-4 definition is properly defined in composer. There's no need to include an autoloader. Any project pulling this in would have it's own.
太厉害了，希望有一天我也能做到