Unable to search metatags with only excluded tags.

Pretty much as the title says, searches like width:>=3200 -absurdres stopped working for me sometime yesterday I believe, is it just me?

forum #65489 last post
Seems to be broken for everyone

Yeah, I noticed it yesterday, too, since it returning a status code 500 was sending a program I've been running everyday into an endless loop.

http://trac.donmai.us/ticket/1353

I checked the trac timeline but nothing jumped out at me.

Same thing here, i use the API for rating:safe -cameltoe and it returns a 500.

I think the problem is that an excluded tag results in a database timeout. It's been doing that for quite a while now, off and on, and getting more frequent, presumably as the number of posts increases. So instead of wasting the time they're just forbidding it. Hopefully Danbooru 2 is doing something smarter than just +all -[tag] and will fix it.

The "source:" metatag no longer works, period. I've tested it with a couple of Pixiv artists that I follow, and it only gave me chickens. This is problematic, since I rely on it for identifying artists far more than the "Find Artist" button, especially when there's a good chunk of artists that don't have an artist entry for "Find Artist" to work.

the source:*cloudfront* and source:*cloudfront* ribbed_sweater still work, at least in my end. but adding negation like source:*www.pixiv* -md5_mismatch -bad_id will fail.

Hillside_Moose said:
The "source:" metatag no longer works, period. I've tested it with a couple of Pixiv artists that I follow, and it only gave me chickens.

A change on 1/12 removed the implicit "*" from the end of source searches. Again, something that should have been announced.

That's a relief, I thought it was just broken.

I think this is on topic here -- try this one:
pool:2168 -if_they_mated

What you should get is chickens, like if you searched pool:2168 -if_they_mated touhou. (Because I used the latter search to track down and tag the remaining images in that series that weren't tagged with it.)

Instead you get an error saying that you can't search with only negative tags despite having a positive pool:* tag. This may or may not be related to the inability to use -pool:* to any effect.

Try my script for filtering tag search results, it should be useful for those searches mentioned in this thread.
http://userscripts.org/scripts/show/124083

BCI_Temp said:
I think this is on topic here -- try this one:
pool:2168 -if_they_mated

What you should get is chickens

Negative queries are hard on the database because they run counter to how the data is organized, and hence they were disabled for instances where there is no positive tag included to help winnow things down.

Metatags like pool: are almost never treated like positive tags because they are implemented differently since they deal with separate tables and (I believe) are joined in after the vanilla portion of the query has executed. Therefore they still trigger the "need positive tags" warning.

I didn't even realize this but I effectively can't do original tagging on old posts anymore with this, the exclusion of bad_id was a fairly critical search modifier what with old posts being far more likely to be deleted than new posts. This is unfortunate as I had only barely made it into the 200k zone.

Perhaps this could be lifted for some metatags? While pool: joins with an external table, date: simply queries a column in the same table the tag list lives, maybe that date query could be run first making an otherwise negative tag only query acceptable?

I'm only marginally familiar with Danbooru's inner workings, so perhaps there's another reason this won't work?

Log said:
I didn't even realize this but I effectively can't do original tagging on old posts anymore with this, the exclusion of bad_id was a fairly critical search modifier what with old posts being far more likely to be deleted than new posts. This is unfortunate as I had only barely made it into the 200k zone.

How about adding "*e*" to your searches as a workaround? You ought to still get a decent return with that.

how about adding just * in the search? * status:any source:*www.pixiv* -md5_mismatch -bad_id returned 21 posts. *e* status:any source:*www.pixiv* -md5_mismatch -bad_id returned 16 posts.

For some reason I thought you needed at least one letter.

Perhaps exclusion-only searches should just be another benefit of being Priv+.

the exclusion of bad_id was a fairly critical search modifier

You could blacklist it temporarily.

Shinjidude said:
Metatags like pool: are almost never treated like positive tags because they are implemented differently since they deal with separate tables and (I believe) are joined in after the vanilla portion of the query has executed.

That makes sense. I guess that also explains why "-pool:" queries don't work either.

RaisingK said:
Perhaps exclusion-only searches should just be another benefit of being Priv+.

Please don't. Being limited to 2 tags was bad enough without any power to winnow down search results intelligently.

So the reason I don't really like supporting this feature is that a malicious user could perform searches like id:>0 -tag and if they spammed this query it could really bring down the database server. There's no way for me to predict a priori whether a metatag will reduce the query to a small subset, or a huge one. It doesn't even have to be malicious in intent, a lot of people just run bots that download every link on a page and they can start exploring the excluded tag searches. I realize it's an extremely powerful tool, but it comes at a cost.

Anyway, for now at least, you should be able to combine -tags with metatags.