you just adopted PHP 7.4 or something similar I think to fix

Thanks for reporting

Nevermind, this is a problem with my setup, sorry for the noise. (I missed the second line, and of course I realized it right after submitting)

Yeah feel free to review D25301

I still like this. Why is this not going forward? 😄

This is now resolved.

In T15583#13304, @avivey wrote:

go for it.

There may already be a feature somewhere to automatically trigger a re-index because the code changed - I'll try to look for one this week.

edit: looks like it's just "add an autopatch" like resources/sql/autopatches/20191028.uriindex.01.rebuild.php. No worries.

This might be a Good Starter Task, I think - you'll need to add a class for the config, and pull the config value in diffusion.

go for it.

Okay, my proposal:

a hack that might work: add a field in the document that's called "typeahead-text" or something, and put both title and callsign into it (and maybe number and short-name as well). Then use that field in the Datasource.
Since this is a full-text field, whatever the user types will fit this field...

Okay, I have tried to wrap my head around the ferret engine. Problem is: the repo callsign is not part of the indexed material. So I would have to construct some query like (just a schema): WHERE ferret-query like '%term%' OR callsign like 'term%' - but that is not possible with the phabricator query engine. The ferret query parts are separatly created and every other where clause is merged with AND. I don't think, there is a clean way out of this. You could make TWO queries: The old one and one with the ferret engine. And then merge the results and remove doubles. But I don't know... just doesn't feel right.

In T15583#13296, @avivey wrote:

I suspect that the code in People is the oldest one - this stuff blames to 2011! and does explicit sql stuff!

rP99c9df96b4ffbf7 (2015) is the big "convert to Full Text Search" commit, but looks like it's not about Ferret (2017?).

I suspect that the code in People is the oldest one - this stuff blames to 2011! and does explicit sql stuff!

I have searched through the code a little bit and there is another system for typeahaed results. It is token based. So, how does it work?

Yeah, that's probably good - that's the query for typeaheads and probably global search, but not for other cases.

There is no ferret involved in my fix. I have already implemented it in our company instance and the devs are loving it. The change is in this line: https://we.phorge.it/source/phorge/browse/master/src/applications/repository/query/PhabricatorRepositoryQuery.php$650

I also don't fully understand the "Phabricator way" to create full text queries still using indexes. That is my main concern.

Yeah, totally reasonable feature request.
Do you think you can implement?
This might involve the Ferret engine (like this thing, or maybe there's a simpler approach for the query (title LIKE %text% in the Query class?).

No interest in this? I can send a diff to differential and be mauled there 🦁

Just to illustrate my point - here are the repositories of phorge: https://we.phorge.it/diffusion/

Cool, I'll play with it and see what I can find.

Okay, I think I created a minimal example reproducing the problem. The repository is publicly available here: https://sourceforge.net/p/tinloaf-phorge-problem/code-hg/ci/default/tree/

Do you know off the top of your head whether the binary-detection in the commit view and the code browser view differ in some way?

To be clear - it's a single file in a single commit, in the equivalent of this page: https://we.phorge.it/rARCa604548101025875de20a9c263df3790fea425b3 - is that right?

To be clear - it's a single file in a single commit, in the equivalent of this page: https://we.phorge.it/rARCa604548101025875de20a9c263df3790fea425b3 - is that right?

Thanks! Now the second step is, finding at least one file that is related to the generation of the above feeds / texts