With the addition of a LIKE parameter to doQUERY(), we would be able to do filtering based on name matches, which is a common request for special pages (bug 6 comes to mind).
Version: unspecified
Severity: enhancement
Description
Description
Details
Details
- Reference
- bz12127
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | Feature | None | T2006 Extend Special:Wantedpages to allow users to search for keywords | ||
| Declined | None | T14127 Addition of "LIKE" parameter to doQuery() |
Event Timeline
Comment Actions
Created attachment 4384
Patch to implement LIKE into doQuery()
This may or may not work, I'm not entirely sure. I'd really like input on the feasibility of this idea, as I think it could greatly enhance our various querypages.
Attached:
Comment Actions
ayg wrote:
- This breaks all existing uses of doQuery that specified $shownavigation. You need to add the new parameter to the end, or make a new method.
- You only support LIKE '%foo%'; is that desirable? Would 'foo%' and '%foo' be useful in some cases? Or maybe '%foo%bar', etc.?
- What effect would using this have on performance?
Comment Actions
- Oops, wasn't paying attention.
- I'm not sure how you would implement that, interface-side. Would you have to give options, such as "begins with/ends with?" Give them ability to put %'s in themselves (very dangerous!), or what? I'm open to ideas, as I hadn't considered that previously. I figured %like% to be a "contains," I suppose.
- A lot, potentially. How does Prefixindex deal with the LIKE?
Comment Actions
ayg wrote:
(In reply to comment #3)
- I'm not sure how you would implement that, interface-side. Would you have to
give options, such as "begins with/ends with?" Give them ability to put %'s in
themselves (very dangerous!), or what? I'm open to ideas, as I hadn't
considered that previously. I figured %like% to be a "contains," I suppose.
I was imagining the caller wouldn't be passing input straight from a form, it would be taking form input and calling based on that. Is this incorrect? I never looked at QueryPage.php, to be honest.
- A lot, potentially. How does Prefixindex deal with the LIKE?
LIKEs where the only wildcard is at the very end of the string (e.g., LIKE 'Foo%') can use an index on the column you're LIKEing. LIKE '%foo%' cannot use an index to retrieve the desired rows, in MySQL -- it has to scan the contents of all rows that otherwise match. I don't know much about the querycache table is used, either, so I don't know whether this is a problem in the specific case. Maybe I'm not the best person to comment on this bug. :)
Comment Actions
All I know is I need Special:PrefixIndex/* or some way to match everything
Special:Allpages with no arguments gets everything.
Special:PrefixIndex with no arguments gets nothing.
Special:Allpages is great, so I link it from the Main Page on
http://radioscanningtw.jidanni.org/), but when the user attempts to
narrow his view, there is no lower bound. That's why
Special:PrefixIndex was invented, apparently.
So I want to link Special:PrefixIndex from my Main Page instead, but
then the user will start out seeing no pages at all and think my site
is empty.
Special:PrefixIndex/* of course gets nothing.
Comment Actions
WONTFIX. Crap bug I filed long before I knew what I was talking about. Adding LIKE to doQuery() is stupid.