Selector operator issue

[doolak]

For a page field i need to use a costum selector to find the selectable pages, which find just the pages which have a text field called "mitglied_name" which contains the letter "a" at the beginning - so i am using this selector:

member_name^=a

Generally it works fine - i just missed a few member names in the list and when i had a deeper look i recognized that words with less then 4 characters are not found.

Can anybody confirm this issue or am i doing something wrong?

[Wanze]

I think you need at least 4 characters for the search:

http://processwire.com/api/selectors/

[WillyC]

mamber_name%^=a

[doolak]

per.fect(!thanks)

[nik]

Actually when using dev-branch, both ^= and %^= are using SQL LIKE and thus both work with short words and MySQL stopwords. Master branch (production version) behaves differently, like described above.

@ryan: Was this the intention?

The change was made here: https://github.com/ryancramerdesign/ProcessWire/commit/0f0be7b60690db9de4af664dbb5b94ef7e6ecef1#wire/core/DatabaseQuerySelectFulltext.php and it actually obsoletes parts of matchContains() method there. Looks like I hit this behaviour with a couple of tests just yesterday (using ^= and not testing %^= at all as I remembered they're the same thing - not so much black box testing...).

[ryan]

In real usage, ^= and $= just aren't that useful when paired with a fulltext index, because fulltext indexes store words, not partials. I actually cant think of any situation where the old fulltext implementation for those is worthwhile. I dont think anyone was using them, as a result. The %^= syntax is far more useful. But I don't want to have something as cryptic as %^= and %$= being part of our official set of operators... Would rather leave it as undocumented and eventually deprecate it, and let ^= and $= take the behavior. That's really how they were supposed to behave in the first place. So that change you linked was my attempt to correct the behavior of those.