La ricerca nel catalogo non si rompe più con un operatore finale

Una pull request unita corregge un bug di vecchia data nella ricerca del catalogo: l’errore MySQL 1064 con un operatore finale.

La richiesta di suggerimento della ricerca invia il termine mentre il visitatore sta ancora digitando, quindi una ricerca come test - arrivava al database con un - finale isolato. In modalità boolean di MySQL è sintassi non valida e la query falliva con l’errore 1064.

Cosa è cambiato

prepareTerms() copiava ogni operatore o parentesi isolato direttamente nella query in modalità boolean, per cui test - produceva "test" -. Il supporto agli operatori non era mai stato davvero utilizzabile: un operatore funzionava solo come parola separata (-brush veniva trattato come frase), test* non troncava mai, e PostgreSQL, SQLite e la ricerca LIKE ignoravano del tutto gli operatori.

Ora ogni parola viene racchiusa tra virgolette doppie e qualsiasi parola composta solo da caratteri operatore o parentesi viene scartata. Il risultato è prevedibile: test - brush trova i prodotti che corrispondono a test o brush, e non esclude più in silenzio brush. Su SQLite le stesse parole vengono scartate, quindi test - non produce più un valore LIKE che non trova nulla, e quel valore non inizia più con uno spazio indesiderato.

Sono stati resi coerenti anche due limiti collegati:

• max_query_words limitava solo i termini, non le parole legate al parametro :query, quindi la query full-text non aveva alcun limite di parole. Ora ce l’ha su ogni database.
• min_query_length si applicava solo all’intero testo di ricerca. Ora ogni parola più corta del minimo viene scartata, su ogni database e sia per la query full-text sia per le condizioni LIKE. Una ricerca LIKE rimasta senza parole non trova alcun prodotto, e l’avviso “Maximum words count” conta le stesse parole che la ricerca usa davvero.

Una ricerca fatta solo di caratteri operatore come --- su SQLite corrispondeva a ogni prodotto; ora non corrisponde a nulla, come su MySQL.