This allows aggregating posts from many sources and loading them
all at the same time at the end of the request, and only if they
being used.
Other potential approaches are to eager preload all posts referenced
by specific entities, but this breaks for thumbnail dtext, which
will be added later.
Tag category updates don't need to run for new tags, and attempting
to run them results in an exception because the tag does not have
a tag id at that point.
The tag counts for the post are still correct as the tag has been
saved and is in the transaction by the time the post system asks
for tag counts for each category, negating the need for the job.
This replaces the old simple versioning helper that existed on
e621. The implementaiton is roughly the same but has been updated
to use newer rails methods.
No, it's not very flexible, but it didn't need to be.
This somewhat gimps the current source information fetching tool,
however it was already a bit suspect, and needs to be reworked before
being released as a public tool because it relies on API calls.
The preprocessor was full of weird problems and allowed for
treating the site as a temporary file store without creating a
post to go with the file uploaded.
A lot of code relies on little bits and pieces of the old query builder,
either for utility functions for returning information in a specific way.
Until all of these code sites have been refactored, the old parser needs
to exist within the codebase for it to continue to operate.
Primarily this impacts various search functions around the site using
the numerical search helper functions.
This avoids using a very hacking preloading scheme that involved
a singleton value that could change at runtime and chaining model
associations together.
While the logic was not particularly complex or spread out it was
made more complicated by the models being dependant on one another.
This creates a central entry point for voting and favorites and
coordinates all transactions.
TODO: upvote/downvote/fav metatags in tag section result in an error
because they attempt to change the transaction isolation mode during
an outer transaction.
This resolves the case where the model update job would be triggered
too soon and miss the committed state for favorites and votes on posts.
The cause of this was larger transaction blocks surrounding updates
and the jobs being queued on the first column update before commit.
This ensures that the post is fully committed before it is queued
for an index update and that all changes are visible in the table.
