[X] My Assistant

It's not.

Really? I can confirm the behaviour described in this post, it does indeed seem that for a searching containing only multiple comment: qualifiers, the default is OR search.

This post has been edited by peterson123: Aug 16 2023, 17:23

comment:video comment:released (misc category)

https://e-hentai.org/g/2643096/c85aa12d67/ only has "released"
https://e-hentai.org/g/2642901/c2360cb8f5/ only has "video"

So it looks like multiple "comment" qualifiers work as OR searches, but is this intended? If I add some non-comment keyword they seem to perfrom as AND again though.

Really? I can confirm the behaviour described in this post, it does indeed seem that for a searching containing only multiple comment: qualifiers, the default is OR search.

Well, looks like you found a bug in the database engine itself, because I checked the debug and we are definitely passing a series of boolean AND terms to it. Which according to the docs means that each word must be present. Which clearly isn't the case for 2643096 and 2642901. I even ran the query it makes directly on the database, and it's definitely matching on those two even though those words clearly aren't both in the text field.

Which means it's not really fixable without rolling out a different indexing system.

If it works by adding some other search term, that's just because the search engine then switches to a different strategy that doesn't use the database fulltext indexes.

Well, looks like you found a bug in the database engine itself [...] not really fixable without rolling out a different indexing system.

Bummer. So I take it that it's a third-party engine? Any chance of filing a bug report with them?

Or else, have the search engine switch to the different strategy even if no additional terms are given?

Well, looks like you found a bug in the database engine itself

Another bug in the database engine it seems. Actually a feature btw.

This post has been edited by naaakful: Aug 16 2023, 22:56

Bummer. So I take it that it's a third-party engine? Any chance of filing a bug report with them?

We're using an older LTS version so it's highly unlikely that it would be fixed for that. I'd need to do some testing to check if it's still an issue on the current version.

Or else, have the search engine switch to the different strategy even if no additional terms are given?

Not possible for performance reasons. It can only use the other (non-indexed) strategy when it has other indexes to work with, which is not the case for comment-only searches.

query: "male on dickgirl" shemale english

results:
https://e-hentai.org/g/2614335/b67cc9bcee/
https://e-hentai.org/g/2612140/744d407027/
https://e-hentai.org/g/2582141/b1ad66229d/
etc don't have "shemale" in them, but only futanari.

Probably due to relations of "male on dickgirl" with futanari/shemale tags or shemale with futanari, but is this correct behavior?

shemale$ or f:shemale works as intended.

It's possibly matching the slaves https://repo.e-hentai.org/tools/taggroup?mastertag=66405 , you should use $ (and quotations for multiple word tags) to match only against the master tag

Matching against slaves (first word or any word on 3 word and higher tags) I believe is intended when $ isn't used.

https://e-hentai.org/?f_search=female%3A%22...+l%3Aenglish%24

https://ehwiki.org/wiki/Gallery_Searching (I know the $ line needs adjusting)

Partial matches on 3+ tags that aren't the first word is a new change so some results not included before may be included now.

It's possibly matching the slaves https://repo.e-hentai.org/tools/taggroup?mastertag=66405 , you should use $ (and quotations for multiple word tags) to match only against the master tag

Matching against slaves (first word or any word on 3 word and higher tags) I believe is intended when $ isn't used.

https://e-hentai.org/?f_search=female%3A%22...+l%3Aenglish%24

https://ehwiki.org/wiki/Gallery_Searching (I know the $ line needs adjusting)

Partial matches on 3+ tags that aren't the first word is a new change so some results not included before may be included now.

I suppose you mean it's matching against "male on shemale" slave, but shouldn't f:shemale (without $) match against it too?
Also, why "shemale" matches "male on shemale", but "male on shemale" in the search gives no results?

This post has been edited by naaakful: Aug 31 2023, 18:22

Not while you are specifying the namespace, unless one of the namespaced slaves has a matching namespace and starts with shemale (as I understand it, I've not tested the recent update)

Not while you are specifying the namespace, unless one of the namespaced slaves has a matching namespace and starts with shemale (as I understand it, I've not tested the recent update)

Ok, I think I got it. After looking closely it seems "shemale" in my case actually matched "sole dickgirl" and "dickgirl on dickgirl" tags, totally forgot about these one sorry.. "Male on shemale" is not working for some reason, though.

This post has been edited by naaakful: Aug 31 2023, 19:14

Ok, I think I got it. After looking closely it seems "shemale" in my case actually matched "sole dickgirl" and "dickgirl on dickgirl" tags. "Male on shemale" is actually not working for some reason.

Yeah, this is working as intended, since there are tags with "shemale" in it slaved to those tags. If you want exact tag matches rather than casual searches that can match titles and slaved tags, you should be using the exact tag operators, like say "male on dickgirl$" shemale$ english$

Yeah, this is working as intended, since there are tags with "shemale" in it slaved to those tags. If you want exact tag matches rather than casual searches that can match titles and slaved tags, you should be using the exact tag operators, like say "male on dickgirl$" shemale$ english$

Shouldn't &skip_mastertags=1 work in this case too? And why "male on shemale" gives no results...

Shouldn't &skip_mastertags=1 work in this case too? And why "male on shemale" gives no results...

skip_mastertags isn't an official toggle, it's just used for some internal tools and only works with single-tag exact searches.

And "male on shemale" isn't a tag.

And "male on shemale" isn't a tag.

It's a slave tag, no?
https://repo.e-hentai.org/tools/taggroup?mastertag=66405

It's a slave tag, no?
https://repo.e-hentai.org/tools/taggroup?mastertag=66405

Yes, but it has the internal "unsearchable" flag due to false positive issues.

(And yes, there are probably a lot more slave tags that should have that flag, or just be deleted outright. The tagging system just hasn't been in a place where the latter has been a real option until very recently, since we can now effectively screen and reject bad added tags.)

Yes, but it has the internal "unsearchable" flag due to false positive issues.

Wow, I never knew such a flag existed. The taggroup tool should mark tags with that flag to avoid confusion (for people who are comparably deep into the mechanics).

An edge case but maye there is an easy fix.

We have the character tag "c.c.".
Searching c:c.c finds all galleries with the tag.
Searching c:c.c. finds nothing.
Searching c:c.c.$ finds all galleries with the tag.

Obviously I would expect the second search to return something as well. This appears to be the case for any tag ending in ".", such as a:aria. or g:"bakuhatsu brs.".

An edge case but maye there is an easy fix.

We have the character tag "c.c.".
Searching c:c.c finds all galleries with the tag.
Searching c:c.c. finds nothing.
Searching c:c.c.$ finds all galleries with the tag.

Obviously I would expect the second search to return something as well. This appears to be the case for any tag ending in ".", such as a:aria. or g:"bakuhatsu brs.".

Hm, yeah, the word boundary check doesn't work if the word ends with a period. I pushed a fix for this, so those should all show the same result now.

Yeah, looks good now, thanks.

Prior to the update there was the option to add "&skip_mastertags=1" to a search url in order to avoid a slaved tag's master from the search. This doesn't seem to work anymore. Could someone confirm that this has been removed?

I see. Well, I took another look at it and it turns out it was a much simpler fix than it initially looked like, so this should be fixed now, but let me know if you encounter any other weirdness using this function. Considering that no one noticed it was broken for 9 months I'm guessing it's not exactly widely used.

skip_mastertags isn't an official toggle, it's just used for some internal tools and only works with single-tag exact searches.

So did you conciously change the behaviour of the flag? E.g. using it with the /tag/ endpoint it seems to work as expected:
https://e-hentai.org/tag/cnaruto
https://e-hentai.org/tag/cnaruto&skip_mastertags=1

But it doesn't work with the f_search option in the URL anymore:
https://e-hentai.org/?f_search=cnaruto
https://e-hentai.org/?f_search=cnaruto&skip_mastertags=1 <- still gives the results of the master.

I'm very sure that before, the latter option would also work. Without that, I don't see how the flag has any merit whatsoever (to a normal user).