You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Sometimes you want to run a search where you only want to see dragons and irl pairs, or some other instance where you want to search for one particular portion of an implied tag and exclude the rest. you cant just search tag, -tag implied by tag, because that would aslo exclude tag, but additionally subtracting all of the other things that imply implied tag are not doable.
Describe the solution you'd like
If we have the ability to search tags in the image search, we could do a join. I know that elastic search doesnt do joins. But given that the only join we want to do is with tags, we could probably do a manual join that runs before the image search.
so say apple -> fruit pear -> fruit orange -> fruit
now extend this out to say 20 fruits
and I want to see all instances of only apples.
I cant just do apple, -fruit, and doing apple, -pear, -orange, -etc... for all 20 tags is a pain)
What I'd like to see is something of the format: tag:(implies:fruit, -apple)
This would return a list of all tags that imply fruit, apple, and then join them together ( pear || orange || etc ) in the search query.
Then you could search apple, -tag:(implies:fruit, -apple) and this preprocessor would catch the tag namespace and run the above on it.
Then the actual image query it would search would be the following join apple, -( pear || orange || grapes || etc)
Because we're only working with the tag namespace, since other ones dont make much sense, this should not be too much to put in addition that it might cause so much jank with the searching. It could be caught with a simple regex, and each query added on before hand.
Additionally, I dont think there is a need for recursive searching within the tag namespace. So I would personally just throw an error in such a query rather than having to code for them.
Also, this will resolve mostly the issue of linking tags together that some people have been hoping for, because tags are already linked internally with implies: or implied_by:
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Sometimes you want to run a search where you only want to see dragons and irl pairs, or some other instance where you want to search for one particular portion of an implied tag and exclude the rest. you cant just search tag, -tag implied by tag, because that would aslo exclude tag, but additionally subtracting all of the other things that imply implied tag are not doable.
Describe the solution you'd like
If we have the ability to search tags in the image search, we could do a join. I know that elastic search doesnt do joins. But given that the only join we want to do is with tags, we could probably do a manual join that runs before the image search.
so say
apple -> fruit
pear -> fruit
orange -> fruit
now extend this out to say 20 fruits
and I want to see all instances of only apples.
I cant just do
apple, -fruit
, and doingapple, -pear, -orange, -etc...
for all 20 tags is a pain)What I'd like to see is something of the format:
tag:(implies:fruit, -apple)
This would return a list of all tags that imply fruit, apple, and then join them together
( pear || orange || etc )
in the search query.Then you could search
apple, -tag:(implies:fruit, -apple)
and this preprocessor would catch the tag namespace and run the above on it.Then the actual image query it would search would be the following join
apple, -( pear || orange || grapes || etc)
Because we're only working with the tag namespace, since other ones dont make much sense, this should not be too much to put in addition that it might cause so much jank with the searching. It could be caught with a simple regex, and each query added on before hand.
Additionally, I dont think there is a need for recursive searching within the tag namespace. So I would personally just throw an error in such a query rather than having to code for them.
Also, this will resolve mostly the issue of linking tags together that some people have been hoping for, because tags are already linked internally with implies: or implied_by:
The text was updated successfully, but these errors were encountered: