[Bug] Pools won't sort by pool order when using sort:pool

[jhaelfire]

Currently, the only way to sort pools is the default sort options. If we could order them inside the pool it would be great and further distinguish pools from tags.

Two frontend changes come to mind:

• Something like the below inside of editing view
• When viewing all posts in a pool, e.g. pool:1, the posts with an order would first be listed, in their order, before the unordered ones by whatever sort order is listed. Posts with the same order number would be listed beside each other, etc.

Also, is there a way to display the pools a post is in, in the normal view? I've been looking around but can't find an option.

[jhaelfire]

Update: Just discovered sort:pool. Appears not to work though.

[liamw1]

When viewing all posts in a pool, e.g. pool:1, the posts with an order would first be listed, in their order, before the unordered ones by whatever sort order is listed. Posts with the same order number would be listed beside each other, etc.

Just discovered sort:pool. Appears not to work though.

As it states in the API, the pool sort-style token sorts posts by the number of pools they appear in. In Szurubooru, pool isn't a valid sort-style token at all; I just added it as one because it was relatively simple to implement and it matches what I did with sort:tag (tag is just an alias for tag-count for sorting purposes).

Why didn't I just have sort:pool sort by pool order? Because it's trickier than it sounds and it's not clear how it could be implemented without introducing strange, uninuitive behavior. Sorts and filters must be able to compose with each other, so any sort must impose a global ordering on posts. One way we could do this is to assign an integer to each post

sort_key = int::MAX * pool_id + pool_order

if the post is in a pool and -1 if it's not present in any pool. int::MAX is there to ensure no collisions. Assuming this operation doesn't overflow (which would only occur if the pool sequence reaches around 2 billion), this assigns a unique integer to every post that's in a pool. Sorting on this value orders posts by what pool there in, and then by the order within that pool.

Except... wait... what if a post is in multiple pools? So, okay, we need some way of determining which pool_id among the associated pools represents each post for the purposes of sorting. We could, somewhat arbitrarily, choose the highest id. But then, consider what happens if I have a post P, which is a member of pools A and B. It also happens to be the only post which is a member of both A and B. Then, I run a search query

pool:A sort:pool

If A was created after B, this works how you would expect: the posts in pool A are shown in pool-order. But if A was created before B, you would see P first, then every other post in A in pool-order. That's because our implementation of pool:sort choose B as the representative pool for post P (since it had the highest ID). Sorting between pools takes priority over sorting within pools, so P comes first regardless of it's position within pool A. Even if we were to fix this issue, it's unclear what should happen if a search query involves multiple pools. Should posts that belong to each pool appear in the search results multiple times? No other search term works like this.

Unfortunately, I don't think this is an issue that can be solved by post search. To fix this, I'll have to re-work how pools are presented in the client, which will most likely be part of a larger client re-write. I have additional plans for pools, as I'm also a bit disappointed by the fact that they're basically just treated as tags. It would be nice to be able to easily re-order posts within a pool in the UI, for instance.

Also, is there a way to display the pools a post is in, in the normal view? I've been looking around but can't find an option.

No, currently pool information only appears in the edit view.

But yeah, for now I'll have to say that these sorts of changes will have to wait until I get around to re-writing the client.