I have found what seems to me an issue with overloading the use of
first_post_id) with two different meanings.
last_post_idmeans, sometimes, highest post id, and other times, post id of the latest post time. However, it is always calculated as highest post id, assuming that the highest post id corresponds to the id of the latest post. This last assumption is FALSE under certain circumstances, and hence, the output is not what is expected. These are rare cases though, but "semantically", the two concepts are incorrectly intermixed in my view.
An example that demonstrates what I mean: we have the following in the posts table in the DB (simplified for clarity):
Code: Select all
Forum Topic Post Time 1 1 1 1 1 1 2 2 1 1 3 3 1 2 4 4 1 2 5 5
Similarly, for first_post_id, forum 1 would have 1, while topic 1 and 2 would have 1 and 4 respectively.
Note that this is true both with the meaning of "lowest/highest" and "earliest/latest".
Now, we duplicate topic 1, delete post 1, and we get the following posts table:
Code: Select all
Forum Topic Post Time 1 1 2 2 1 1 3 3 1 2 4 4 1 2 5 5 1 3 6 1 1 3 7 2 1 3 8 3
And the issue also manifests for first_post_id: now it would be 2 (lowest) while the "earliest" would have to be 6.
In my opinion, it should be clear what "semantics" we want to apply to "last_post_id" in each situation, and act accordingly.
First and last are used with the meaning of lowest and highest, for example, when resynchronizing counters.
And are intented to be used with the meaning of earliest and latest when applied to topics and forums.
Related to this, but totally different problem, is the following: if you have an "unapproved" post, and before it gets approved, there are other posts in the same topic (that might not need approval), if someone visits the topic, the "unapproved" post will show as read when approved, and it should not. Besides, it is listed in "publication" order, but it should probably be listed in "approval" order (to be consistent to when this post was VISIBLE to everyone with the right permissions).
These applies both to 3.1 and 3.2; I have not tested master, but I guess it would be the same. What do you think? Should this be fixed, or leave it as is, given that the inconsistencies are corner cases? By the way, these "corner cases" are more frequent when you use the "MCP Change Post Time" extension, as you are manipulating the timeline (but not the post ids), that is why I got to this... Anyhow, the inconsistencies are there without any extension, so clearly a core "bug" or "feature"...
Before you ask: this change should not result in (almost) any performance impact, as the posts table is indexed both on post_id and post_time.