These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

Player Features and Ideas Discussion

 
  • Topic is locked indefinitely.
 

Double posting in the Forums
Author
Previous Topic Next Topic
Nora Smith
Fitzpatrick Royal Nuclear Products
#1 - 2012-04-29 21:24:15 UTC
Hi,

I often stumble upon threads with a lot of double posts - even had this problem once or twice myself due to unvoluntarily clicking twice on the "Post" button, or just having the board give me an error, sending again, and BAM, double kill.

I'd like to propose a small change in the board software (which is a CCP inhouse development if I remember correctly):

Just put a unique ID (GUID, a timestamp plus user ID or whatever) in the posting form, and add this to the post storage table in the database. If a posting with the same user and unique ID comes in, either replace the existing entry or simply ignore the second try and throw an error. If you're really, really paranoid and don't like people tampering with the ID (e.g. with their browser's devtools) you could store it server-side in the user's session.
mxzf
Shovel Bros
#2 - 2012-04-29 22:07:07 UTC
Sounds like you want to add overhead to try to solve something which really isn't much of an issue to begin with. Just ignore the DP, it's not that big a deal (and storing a GUID for every single forum post would be far more overhead than just leaving the extra posts where they are).
Shish Tukay
Caldari Provisions
Caldari State
#3 - 2012-04-29 22:41:43 UTC
Not sure why an extra field needs adding - should the content of the post not be unique already? Just check if the user-and-content of the current post is the same as the user-and-content of the most recent post in the thread; if it is, don't duplicate it.

(This would stop people posting the same thing over and over deliberately, but oh well :P If that behaviour is really wanted, one could check user / content / last 30 seconds)
Master Tarn
Keeping Up Appearances
#4 - 2012-04-30 09:11:31 UTC
i concur...
Master Tarn
Keeping Up Appearances
#5 - 2012-04-30 09:11:41 UTC
i concur...
Nora Smith
Fitzpatrick Royal Nuclear Products
#6 - 2012-04-30 10:04:36 UTC
Shish Tukay wrote:
Not sure why an extra field needs adding - should the content of the post not be unique already? Just check if the user-and-content of the current post is the same as the user-and-content of the most recent post in the thread; if it is, don't duplicate it.

(This would stop people posting the same thing over and over deliberately, but oh well :P If that behaviour is really wanted, one could check user / content / last 30 seconds)


Full-text comparison with each post is a costly operation, adding another column to a table and putting a unique index on it isn't much of an overhead, putting aside the one-time load for altering the table structure.

Sure, it's just a minor annoyance, but if it's easy to fix with a few lines of codes, why not give it a try? :)
Shish Tukay
Caldari Provisions
Caldari State
#7 - 2012-04-30 20:43:57 UTC
Nora Smith wrote:
Full-text comparison with each post is a costly operation

No it isn't o_O

http://pastebin.com/zFy1Abuj


Artificially engineered worst case (both posts use the full 6000 characters, and there are no differences):

100,000 compares: 0.48s
100,000 GUIDs: 1.68s

Text comparison wins by 3x


Best case (the posts differ starting with the first character, so a difference is spotted right away):

100,000 compares: 0.02s
100,000 GUIDs: 1.67s

Text comparison wins by 83x


You could swap a GUID for a mostly-probably-unique-ID in order to generate them faster. Taking your example of user ID + timestamp, we get:

100,000 compares: 0.02s
100,000 IDs: 0.05s

Text comparison is still twice as fast :P


(Results may vary slightly between python and whatever language is hiding behind that .aspx extension, and I've also made some simplifications and approximations that I can justify if need be; but I think my point of "measure; don't assume" has been made :3 I can also explain /why/ text matching is faster, but you can figure that out for yourself by implementing each algorithm in C and looking at the generated machine code ^_^)