sqlite_ext.FTSModel: MATCH'ing a single column
==============================================
SQLite FTS allows MATCH'ing a single column instead of the full table. An example from https://www.sqlite.org/fts3.html:
```sql
-- Example schema
CREATE VIRTUAL TABLE mail USING fts3(subject, body);
-- Example table population
INSERT INTO mail(docid, subject, body) VALUES(1, 'software feedback', 'found it too slow');
INSERT INTO mail(docid, subject, body) VALUES(2, 'software feedback', 'no feedback');
INSERT INTO mail(docid, subject, body) VALUES(3, 'slow lunch order', 'was a software problem');
-- Example queries
SELECT * FROM mail WHERE subject MATCH 'software'; -- Selects rows 1 and 2
SELECT * FROM mail WHERE body MATCH 'feedback'; -- Selects row 2
SELECT * FROM mail WHERE mail MATCH 'software'; -- Selects rows 1, 2 and 3
SELECT * FROM mail WHERE mail MATCH 'slow'; -- Selects rows 1 and 3
```
Naturally (to me) one would want to write the column matching code like this:
```py
# SELECT * FROM mail WHERE subject MATCH 'software';
Mail.select().where(Mail.subject.match('software'))
```
However, this doesn't work, and instead it seems one has to write
```py
from playhouse.sqlite_ext import match
Mail.select().where(match(Mail.subject, 'software'))
```
and the `match` function isn't documented; only the `match` method of `FTSModel` is documented.
Maybe a `match` method could be added to `SearchField`?
Please excuse me if I missed anything obvious.
Guess I can't resist the urge to leave a final comment on the "if you want an option, just make a tap" thing.
As the 15th most prolific contributor to core I'm apparently no stranger to taps. Setting aside barrier of entry, discoverability, mental overhead, physical overhead, etc. when it comes to taps, I used to be able to add a harmless option to a formula, and it would enjoy all further contributions to the formula, be it updates or bug fixes. (It may cause problems down the road, but those were never high priority, maintainers worked on them when they felt like it, or just ignored those.) Now, in order to add an option, I need to maintain a formula indefinitely. Having been responsible for `ffmpeg` & `imagemagick` for a long time, I know how fun that is.
Over the years I encouraged many projects to move their tap into core. I didn't know I would one day advise moving out of core...
But the ship has sailed, so whatever.
Okay, I haven’t been following Homebrew politics since I left. So the new official stance is making options a thing of the past? Throwing out years of work by hundreds/thousands of people and throwing “power users” under the bus? Okay.
I don’t care enough to fight for this, free feel to close.
That said, my observation is “we might make it the default if is useful to many users” is both inconsistent and very subjective. If “useful to many users” is the criterion for default, then `--with-fts` should probably be the default. (Same conclusion if you appeal to Debian.) Also, how many is many? 100? 30%? Not clear. Given that ICU support was there for very long and nobody cared to add it before me, it can be argued that it’s probably not useful to a wide audience; but same can be said about adding any option to any established package.
Speaking of Debian, they once added ICU support, then removed it, saying “it causes more trouble than good”, without linking a bug. The only linked “bug” about ICU in the changlog is package author screwing up ldflags for libicu, so it’s not clear what’s the trouble that got it removed. And that was 2009, so it reflects little on today.
On an unrelated note, I checked gentoo and they offer ICU:
https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-db/sqlite/sqlite-3.25.3.ebuild
sqlite: add --with-icu4c option
===============================
- [x] Have you followed the [guidelines for contributing](https://github.com/Homebrew/homebrew-core/blob/master/CONTRIBUTING.md)?
- [x] Have you checked that there aren't other open [pull requests](https://github.com/Homebrew/homebrew-core/pulls) for the same formula update/change?
- [x] Have you built your formula locally with `brew install --build-from-source <formula>`, where `<formula>` is the name of the formula you're submitting?
- [x] Is your test running fine `brew test <formula>`, where `<formula>` is the name of the formula you're submitting?
- [x] Does your build pass `brew audit --strict <formula>` (after doing `brew install <formula>`)?
-----
`--with-icu4c` enables the ICU tokenizer, which makes full-text search of CJK text possible.