🐛 Fix FullTextSearch if property is null

[elyanory]

Hello !

I'm currently using sulu 2.5.22 in production which uses your bundle. When I try to do a fullTextSearch on a :

$queryBuilder->andWhere(
    $this->qomFactory->fullTextSearch(
        selectorName: 'node',
        propertyName: null,
        fullTextSearchExpression: $filters['search_term']
    )
);

This doesn't work. However, when I look at the documentation, we can set the propertyName to null to search the entire node, but this doesn't work because https://github.com/jackalope/jackalope-doctrine-dbal/blob/2.x/src/Jackalope/Transport/DoctrineDBAL/Query/QOMWalker.php#L827 doesn't accept a null property, or at least it doesn't work with MySQL.

Here's a fix that works for me. Don't hesitate to send me feedback. I haven't taken the time to add the tests yet.

[dbu]

thank you for looking into this! it looks plausible and seems to make sense.

to be sure the functionality works, and to double-check behaviour with jackrabbit, could you add a test case to https://github.com/phpcr/phpcr-api-tests ? (as this is phpcr spec behaviour, the functional test is enough, i don't see need for an additional unit test in this repository)

it should be failing with this repo but hopefully works with jackrabbit already, and would then be fixed by this merge request.

[dbu]

does it make sense to have a parameter with default value for $column? if i understand correctly, this parameter is never changed, so we should use 'props' directly - or set up a constant in the class.

[elyanory]

@dbu I think you're right, we could remove $column. When I look at the method above, it's hard-coded (

jackalope-doctrine-dbal/src/Jackalope/Transport/DoctrineDBAL/Query/QOMWalker.php

Line 886 in 8d0ad92

private function sqlXpathExtractNumValue(string $alias, string $property): string

). I can do the same thing here. But what impact will that have? It's BC, isn't it?

[dbu]

the joy of private methods is that we only need to validate in this class. if nothing in this class passes the 3rd parameter, removing the parameter is backwards compatible.
if it really is unused, it was either used in the past and then the code changed but nobody noticed its not needed, or it was some future-feature that did not happen. as its a private method, we can just add it back in should the need arise.

for the new method, it certainly is not an issue to remove it, because you only add it right now.