-1 replies?!?!

[Katarok]

When your reply is so unhelpful that the forum takes away a reply count.





Yes I do know that there can be errors in counting such and such I am just a making fun of it, no need to explain it in the replies

[Sarra]

7 hours ago, Katarok said:

When your reply is so unhelpful that the forum takes away a reply count.





Yes I do know that there can be errors in counting such and such I am just a making fun of it, no need to explain it in the replies

For a moment, I thought I was on reddit, and you were talking about my karma...

[Quackers101]

I love -0

[Spotty]

8 hours ago, Katarok said:

Yes I do know that there can be errors in counting such and such I am just a making fun of it, no need to explain it in the replies

Well I'm going to explain anyway.

 

Topics get posted and then it counts the number of posts in the topic. The number of replies shown in the recent topics list are the number of posts -1 (since the original post doesn't count as a reply). The recent topics side panel is cached and updates every minute or so. It will show -1 replies if the forum caches the recent topics in between the time that the thread is created and the number of posts in the thread is counted. It's pretty uncommon, but because the side panel is cached and displayed for everyone when it does happen there tends to be a few people who notice it. It'll correct itself the next time the recent topics list updates itself.

[The Blackhat]

8 hours ago, Katarok said:

When your reply is so unhelpful that the forum takes away a reply count.





Yes I do know that there can be errors in counting such and such I am just a making fun of it, no need to explain it in the replies

When @ragnarok0273 replies to a post.

[WhitetailAni]

2 minutes ago, The Blackhat said:

When @ragnarok0273 replies to a post.

Oof.

I saw this before (I think in November)?

 

EDIT:
I didn't realize I was famous enough to have haters.

Wait - I'm not famous anymore.

I'm "Admired".

I kinda preferred being "Famous".

[kelvinhall05]

1 minute ago, ragnarok0273 said:

Oof.

I saw this before (I think in November)?

[WhitetailAni]

Just now, kelvinhall05 said:

I seriously do that?
Cool!

[Rybo]

11 hours ago, Spotty said:

Well I'm going to explain anyway.

 

Topics get posted and then it counts the number of posts in the topic. The number of replies shown in the recent topics list are the number of posts -1 (since the original post doesn't count as a reply). The recent topics side panel is cached and updates every minute or so. It will show -1 replies if the forum caches the recent topics in between the time that the thread is created and the number of posts in the thread is counted. It's pretty uncommon, but because the side panel is cached and displayed for everyone when it does happen there tends to be a few people who notice it. It'll correct itself the next time the recent topics list updates itself.

Well now you got the software engineer in me revved up.  So there's a separate service regularly polling the database to count & cache the number of replies in threads and also a separate service creating/caching the recent topics panel?  So the sequence is something like this?

1) Thread created
2) Recent Topic Polling Service activates
3) RTPS sees new thread
4) RTPS requests reply count
5) Thread Reply Count Service has no values for the requested thread
6) RTPS shrugs and puts in the default value of -1

 

I started to ask myself why you wouldn't just go to the source on a cache miss, but the answer was apparent: for such a trivial piece of data, the value of increasing the efficiency of the forum outweighs it by several orders of magnitude.  

[colonel_mortis]

7 hours ago, Rybo said:

Well now you got the software engineer in me revved up.  So there's a separate service regularly polling the database to count & cache the number of replies in threads and also a separate service creating/caching the recent topics panel?  So the sequence is something like this?

1) Thread created
2) Recent Topic Polling Service activates
3) RTPS sees new thread
4) RTPS requests reply count
5) Thread Reply Count Service has no values for the requested thread
6) RTPS shrugs and puts in the default value of -1

 

I started to ask myself why you wouldn't just go to the source on a cache miss, but the answer was apparent: for such a trivial piece of data, the value of increasing the efficiency of the forum outweighs it by several orders of magnitude.  

It's not as complex as that. If user A is submitting a new topic, and user B is loading an arbitrary page:

1. For user A, the "topic" record is inserted into the database, with 0 posts (including no OP)
2. For user B, the forum notices that the cached recent topics widget is out of date
3. For user B, the forum retrieves the 5 most recent topics from the database, including user A's topic
4. For user B, the forum renders the widget, setting numReplies = count(topic.posts) - 1 [= -1 here]
5. For user A, the "post" record for their topic is inserted into the database

1 and 2 are interchangeable, as are 4 and 5 - it's the 1 -> 3 -> 5 sequence that matters here.

 

This could be solved using transactions, which enforce an ordering between all of A's operations and all of B's to prevent this. However, the forum software we're using doesn't support that.

[linuxChips2600]

13 minutes ago, colonel_mortis said:

However, the forum software we're using doesn't support that.

Is it open source or relies on some free and publicly available API/software-library? If so I'd like to take a crack at it and see what I can come up with (not that I actually expect to fix any issues); as someone looking into web dev I'm interested in taking a gander at what stuff is out there, so to speak.

FYI I'm taking a computer science database class this semester so this could be a fun side project of sorts lolz.

Edited February 1, 2021 by linuxChips2600
Give extra context

[PorkishPig]

15 minutes ago, linuxChips2600 said:

Is it open source or relies on some free and publicly available API/software-library?

Nope, Invision is very not free. https://invisioncommunity.com/buy/self-hosted/

[colonel_mortis]

19 minutes ago, linuxChips2600 said:

Is it open source or relies on some free and publicly available API/software-library? If so I'd like to take a crack at it and see what I can come up with (not that I actually expect to fix any issues); as someone looking into web dev I'm interested in taking a gander at what stuff is out there, so to speak.

FYI I'm taking a computer science database class this semester so this could be a fun side project of sorts lolz.

Unfortunately it's not open or available source.

 

It's also not something that can easily be changed - supporting transactions in a meaningful way would likely involve completely rearchitecting the code, because database accesses are spread out throughout it. A naive solution, like just starting a transaction at the start of the request and committing at the end, would still run into issues where one thing (such as the post creation in the example above) but some side effects still need to be seen, so it would end up being very difficult to retrofit in any practical way.

[akio123008]

Is there not just some operation that can be done after the fact (maybe even on the client side) that sets any negative value to 0? Essentially allowing the system to report a negative number, but not delivering that to the user?

 

basically if( x < 0 ) then x = 0;

 

[Rybo]

14 hours ago, akio123008 said:

Is there not just some operation that can be done after the fact (maybe even on the client side) that sets any negative value to 0? Essentially allowing the system to report a negative number, but not delivering that to the user?

 

basically if( x < 0 ) then x = 0;

 

There are dozens of patchwork remedies to the solution, but when you apply band-aids to race conditions, the blood tends to just seep out elsewhere -- that or it doesn't cover the whole wound.  The real solution is to eliminate the race condition -- i.e., wrap the thing in a transaction.  Or in this forum's case, raise a bug with the vendor and be proud that you notified them of a problem that will never be solved.  In this case, it seems like a reasonable solution to the problem -- after all, there will never be fewer than 0 replies -- but it may leave some other bug unsolved.  By the end of it there will be weird band-aids and predicates throughout the system for the one issue that you didn't feel like solving right the first time  

 

15 hours ago, colonel_mortis said:

 

Ah, that makes sense.  I wouldn't think the "topic" and "post" were two different records, but I guess it makes sense if you're on a version of MySQL that doesn't support recursion (IIRC the software is on MySQL -- and even if the version has been upgraded, it's reasonable to assume it was developed before recursion was supported!).  Or, y'know, the developers didn't want to tie a Gordian knot in their forum software.  

[colonel_mortis]

On 2/1/2021 at 10:12 PM, akio123008 said:

Is there not just some operation that can be done after the fact (maybe even on the client side) that sets any negative value to 0? Essentially allowing the system to report a negative number, but not delivering that to the user?

 

basically if( x < 0 ) then x = 0;

 

Yeah, we could, but it's a pretty rare race condition, caused by a very tight race, so it's not been worth it.

9 hours ago, Rybo said:

Ah, that makes sense.  I wouldn't think the "topic" and "post" were two different records, but I guess it makes sense if you're on a version of MySQL that doesn't support recursion (IIRC the software is on MySQL -- and even if the version has been upgraded, it's reasonable to assume it was developed before recursion was supported!).  Or, y'know, the developers didn't want to tie a Gordian knot in their forum software.  

There are multiple posts per topic, so unless the first post gets included in the topic record and the others are stored separately (which would result in a nightmare amount of special casing and keeping things in sync) I'm not sure how that could work - I'm curious how you would expect that to work.

[Rybo]

14 minutes ago, colonel_mortis said:

There are multiple posts per topic, so unless the first post gets included in the topic record and the others are stored separately (which would result in a nightmare amount of special casing and keeping things in sync) I'm not sure how that could work - I'm curious how you would expect that to work.

This is SQL Server syntax, but hopefully it should still be legible.  It's also pretty ad hoc, so syntax errors are...likely.  
 

-- create single posts table
create tblPosts as (PostID int, Title varchar(max), Content varchar(max), ParentID int, DateCreated datetime2)

-- to create a new topic; notice parent ID of 0
insert into tblPosts values (1, 'New topic!', 'content!', 0, GETDATE());

-- to 'reply' to the topic
insert into tblPosts values (2, 'Optional response title!', 'content!', 1, GETDATE());

-- bonus feature: respond to responses!
insert into tblPosts values (3, 'Optional response title!', 'content!', 2, GETDATE());

--get all topics
select * from tblPosts where ParentID = 0 order by PostID asc;

--get full tree from a given PostID
declare @postID int = 1
with posts as (
     select * from tblPosts where PostID = @postID
     union all
     select * from tblPosts child 
     inner join posts parent where child.ParentID = parent.PostID
)
select * from posts order by PostID asc;

The mind-twisting part is the CTE, which is the last bit in the code block.  As all recursion is, it is self referencing.  The first half of the union represents the "base case", and the second part will query any posts with that parent's post ID as a parent ID.  Then it'll circle back around and query every post that has that result set's post ID as a parent ID.  This also has another bonus feature that, in loooong reply chains, you can chop off the head and just treat some random post as the topic (reddit does this extensively).  

[colonel_mortis]

14 minutes ago, Rybo said:

This is SQL Server syntax, but hopefully it should still be legible.  It's also pretty ad hoc, so syntax errors are...likely.  
 

-- create single posts table
create tblPosts as (PostID int, Title varchar(max), Content varchar(max), ParentID int, DateCreated datetime2)

-- to create a new topic; notice parent ID of 0
insert into tblPosts values (1, 'New topic!', 'content!', 0, GETDATE());

-- to 'reply' to the topic
insert into tblPosts values (2, 'Optional response title!', 'content!', 1, GETDATE());

-- bonus feature: respond to responses!
insert into tblPosts values (3, 'Optional response title!', 'content!', 2, GETDATE());

--get all topics
select * from tblPosts where ParentID = 0 order by PostID asc;

--get full tree from a given PostID
declare @postID int = 1
with posts as (
     select * from tblPosts where PostID = @postID
     union all
     select * from tblPosts child 
     inner join posts parent where child.ParentID = parent.PostID
)
select * from posts order by PostID asc;

The mind-twisting part is the CTE, which is the last bit in the code block.  As all recursion is, it is self referencing.  The first half of the union represents the "base case", and the second part will query any posts with that parent's post ID as a parent ID.  Then it'll circle back around and query every post that has that result set's post ID as a parent ID.  This also has another bonus feature that, in loooong reply chains, you can chop off the head and just treat some random post as the topic (reddit does this extensively).  

There's a bunch of extra metadata on topics beyond that of the posts it contains (mostly denormalized data for efficient rendering, such as the number of posts or last reply), which you could put on a post but it just ends up making things unnecessarily complicated for no particular benefit.

 

Having a linked list of posts rather than just parenting them to the topic makes sense if you have a tree of replies (such as in Reddit), but not so much when it's just a linked list as it would be here - to get to page 41, you have to traverse the 1000 posts on pages 1 through 40 first, rather than potentially utilising an index, and stuff goes weird when you start removing posts. Interesting idea, but I don't think it would work for a forum structured like this.

[Rybo]

17 minutes ago, colonel_mortis said:

Having a linked list of posts rather than just parenting them to the topic makes sense if you have a tree of replies (such as in Reddit), but not so much when it's just a linked list as it would be here - to get to page 41, you have to traverse the 1000 posts on pages 1 through 40 first, rather than potentially utilising an index, and stuff goes weird when you start removing posts. Interesting idea, but I don't think it would work for a forum structured like this.

Keep in mind that replying to replies is a fringe benefit that you don't have to utilize.  Thus, the tree can be one layer deep: the topic with a parent ID of 0 and 0 to 4 some-odd billion replies with a parent ID of 1.  So you'd get most of the benefits of having a separate 'topics' and 'posts' table -- decent indexing, windowing functions should work, etc, with the atomicity of a post and all of its relevant metadata springing into existence at the same time.  
 

[Spotty]

3 hours ago, Rybo said:

So you'd get most of the benefits of having a separate 'topics' and 'posts' table

Wouldn't having topics and replies in separate tables cause further complicatons when merging or splitting posts? If you merge a post you would need to turn the topic in to a reply. Vice versa for splitting replies off in to their own thread where a reply would become a topic.

 

It's pretty rare to see -1 posts in the recent topic list, and aside from a little confusion on the off chance someone even notices it, it doesn't cause any actual problems. 

[BlueChinchillaEatingDorito]

I think the only time I've seen that was right after the forum update back in November or some time around there. Was more common then since there were performance issues with the recent posts section. So it was pretty common to see that or post counts not matching up with the count on the subforum page. 

[Rybo]

10 hours ago, Spotty said:

Wouldn't having topics and replies in separate tables cause further complicatons when merging or splitting posts? If you merge a post you would need to turn the topic in to a reply. Vice versa for splitting replies off in to their own thread where a reply would become a topic.

 

It's pretty rare to see -1 posts in the recent topic list, and aside from a little confusion on the off chance someone even notices it, it doesn't cause any actual problems. 

Yeah, that's what I've been getting at.  The benefits I was referring to were at the system level: performance benefits, primarily.  The costs of maintaining two different tables are: you either have to wrap topic creation into a transaction (which this forum's vendor software didn't do) or put patches and band-aids all throughout the app (which I suspect they attempted to do, albeit incompletely).