Live data from Hacker News

Show HN: PHP-fts – Full-text search engine in pure PHP, no extensions

github.com

11–20 of 35 posts

Re: Show HN: PHP-fts – Full-text search engine in pure PHP, no extensions

#11
post #5
post #4

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.

Re: Show HN: PHP-fts – Full-text search engine in pure PHP, no extensions

#12
post #7
post #6

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 in…

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…

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.

Re: Show HN: PHP-fts – Full-text search engine in pure PHP, no extensions

#15
post #12
post #7

Earlier quoted context omitted.

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…

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.

Re: Show HN: PHP-fts – Full-text search engine in pure PHP, no extensions

#16
post #15
post #12

Earlier quoted context omitted.

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

Re: Show HN: PHP-fts – Full-text search engine in pure PHP, no extensions

#18
post #16
post #15

Earlier quoted context omitted.

> 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.

Post reply on HN