Unfortunately there's no good way to implement the user-facing side of this, and the only way to implement it in the backend is extremely hacky and probably wouldn't work very well.
On the user-facing side, tag searches can have any number of tags in them, which creates a situation where a tag like this would be ambiguous. If you were to search for "black_hair long_hair sort:added", for example, would it sort them by the order in which "black_hair" was added? Or would it sort them by the order in which "long_hair" was added? Or would it only return posts in which both tags were returned at the same time? Keep in mind that the order tags appear in a search cannot change what the search does, so we can't just have it always use the first tag, or the tag just before or just after the metatag.
On the backend, ALL of a post's tags are stored in a single text field in the posts table, and all that the posts table keeps track of is when this entire field was last changed, regardless of which tags, if any, got added or removed. The only place in the database we keep track of what time a specific tag was added is the tag edit history table, which is not indexed in our search. The favorites and pools tables also weren't indexed and we managed to hack in a way to use them, but this was definitely a hack and had some pretty major limitations. For example, users with more than 25k favorites can't use this feature at all, and pools larger than 50k posts can't be searched either. Given that the tag edit history table is quite large, the limit for a search accessing the tag history table would probably be even lower. I can't really say what the limitations would be without us actually trying to implement it, but I can say for certain that your example of using it for the "bikini" tag with around 300k posts would just give you a "Too may items to search" error. |
