I've moved the thumbnails around many times over this project
and hopefully it doesn't happen too many more. Once the database has
tens of thousands of items, the thumbnails start to become the biggest
headache on the disk. Backing up, restoring, and sharding files per
directory are slower and more effortful with separate files. In the db
means the db is a larger file, but this is disk space that was already
getting used anyway. Now it's simpler and has atomic transactions.
The initial motivation for this was to make the "more_after_limit"
feature, which would help the UI to not show a next page button when
the number of results was exactly equal to the limit.
However, in order to surface this more_after_limit status using only
the old search generator, it would have to be a special yield at the
end. I was getting tired of the special yields like give_back_params
at the beginning and warning_bag at the end, and this would be worse.
There is a lot of sideband information about the search that is now
more easily accessible when the search is its own object.
Previously, the whole walk tree was returned. This can be convenient
because you get the whole descendant tree all at once, but it's
unusual since all the other individual .json endpoints only return a
single object, not a list.
The cached_endpoint decorator was detecting that the response content
kept changing, so it never returned 304. Oops. At the moment the client
doesn't even use this key, so if we need it back we can use the etag or
another http header.