BTW its probably time to make it 5.0, not 2.0

Relatively little doom appears to have befallen us.

This hasn't seen action in two years and a lot of the surrounding code has changed since then. If it's still an issue, please file a new bug report with reproduction steps demonstrating how to break an object so it doesn't index properly.

Thanks for clarifying

The section in T11922 only applies to the storage engine portion of that change, not to reindexing in general, and dropping the index is likely to hurt things overall if we need to do this more in the future (no performance improvement but totally nukes the search index until the reindex occurs).

Should the description here include the section from T11922 about minimizing downtime? The release notes link to T11922 and not here, but someone from IRC had been going based on the information in this task without seeing that note which may have saved them some indexing time.

This one is fine, I'm still going to fiddle with "in" too.

In T8510#200946, @aklapper wrote:

In https://phabricator.wikimedia.org/T76732#2803813 ksmith brings up that

In the search bar in the toolbar at the top of the screen, searching for "Maps" brings up Maps as the third option. Searching for "Discovery" brings up Discovery as the second option.
When editing a task and entering tags, autocomplete does bring up Maps and Discovery as the first items.

but that could be a separate (unprioritized) task I guess.

In https://phabricator.wikimedia.org/T76732#2803813 ksmith brings up that

In the search bar in the toolbar at the top of the screen, searching for "Maps" brings up Maps as the third option. Searching for "Discovery" brings up Discovery as the second option.
When editing a task and entering tags, autocomplete does bring up Maps and Discovery as the first items.

but that could be a separate (unprioritized) task I guess.

Ah, thanks! I've asked downstream if anyone still runs into any issues, but so far I also believe this is now resolved.

The most-likely-to-work secret magic for "Not in: Wikidata" is not(wikidata):

phabricator.wikimedia.org is running a version including these changes plus D16886 on top. So far it looks like a great improvement!

I caught another case of this: here, "Phacility" should be first, but is not.

I believe this is now resolved, in the sense that I expect all specific, reproducible examples I'm aware of function in a way consistent with user expectation. In particular:

I have some possible approaches for cheating on the "more than 100 results" case, but I think we ultimately need to put the prefix paging rule on the server side, so we return all prefix matches and then all content matches. That's kind of a big mess, but all the ways we can cheat will break down at some point (e.g., when you have 100 "wikidata" projects that are alphabetically earlier than "wikidata") so I think it's not avoidable.

This is expected.

@epriestley:
So far innodb is working. I can't say if it's worse than myisam really, seems pretty similar. Stemming would help a lot but the main complaint I have is the ranking algorithm seems really bad. It doesn't return the most relevant results first. myisam had the same problem though.

We're planning to put application-level stemming on the MySQL index (see T6740). Are there problems with the InnoDB search that you're aware of that aren't fixable with application adjustments?

With InnoDB now mostly finished indexing, search seems to be working and the service isn't getting killed by locked tables. More info at the link I pasted above ^

Wikimedia is considering another stab at elasticsearch because we just hit a fairly serious scalability issue with myisam (https://phabricator.wikimedia.org/T146673) and it looks like innodb isn't a lot better. In addition to that, the mysql fulltext engines don't seem to handle stemming or even simple prefix matching.

I hit this as well - I was able to fix the handful of tasks created before setting "search" -> "true" by just re-saving those tasks.

Yes, if you want the change to apply retroactively. Something like bin/repository reparse --message --all rXYZ, but see bin/repository help reparse first to test that on a few commits and make sure it does what you want.

Ok, I understand.

There is no such setting, and I believe this use case is very unusual -- it's like putting the subject line of email in the first line of the body -- so I currently have no plans to add support for it (see also T8227).

We actually have some problems with our phabricator install.
We use it with mysql, but in a Galera (PXC) cluster and it does not work well with myisam tables.

Perhaps in a separate change, it would be nice to maybe show the application name under the more modern document types -- for example, show "Diffusion" here:

To reach this dialog, mash some text into the search field in the global menu bar, then hit enter.

Ran into this today on this install. Seatrched for open/close tasks with term "javascript".
https://secure.phabricator.com/search/query/qi_sDFEgnw9i/#R

At HEAD of master, this is now supported. There's no default UI for it, but you can get to it in three ways:

Just bookkeeping; this doesn't have an active external priority driver.

Thanks for testing, that's quite helpful.

In T8510#179818, @epriestley wrote:

D16094 should improve things, let me know if you identify specific problems after deploying that. It's deployed on this server now, although we have fewer similarly-named projects so it's harder to see the effects.

D16094 should improve things, let me know if you identify specific problems after deploying that. It's deployed on this server now, although we have fewer similarly-named projects so it's harder to see the effects.

It's expected that the ordering in "Browse" is alphabetical/raw, and I don't plan to change that.

Here's what happens when adding wikidata project tag using the comment form typeahead:

Here's at least one specific reproduction case which still isn't working well:

(I marked D15981 as fixing this but I'm going to leave it open for confirmation since I'm not completely sure there weren't more cases that I missed.)

T6102 and the downstream also contain discussion of a second case which does center around exact matches -- searching for "Wikidata" -- but I can't reproduce it at HEAD:

D15981 doesn't, strictly speaking, prioritize exact matches. However, it should fix the underlying issue.

In T10640#166457, @Taskle wrote:

the UX problem here for us is that all of our employees are using global search when they don't realize it because it's top right when they go to the phab homepage, when in reality they only use Phab for Maniphest tasks.

I'd love it if I could just click on the "Blocked by" or "Blocks" label on a task and be taken to the Maniphest query for all the listed tasks.

My example for this problem was with Maniphest tasks in T10790, where identical task titles is problematic in the search results.

I'm just going to merge this into T10337, which discusses providing modern endpoints. repository.create is a broken mess and we tend to replace it rather than fixing it (it can't reasonably be fixed without breaking the API, anyway, so we'd end up with a new endpoint in effect, regardless). The new diffusion.edit will fix this and the many other problems with repository.create.

@epriestley I understand you have the setup check - my point is that for RDS users we skip this check when we see we can't do anything about it. And then months later it's forgotten about and we still draw that conclusion.