Hancoque Posted December 31, 2004 Posted December 31, 2004 I'm quite unhappy with how the member numbers (e.g. "Member No.: x" in the topic view) are "calculated". The member number is currently just the ID of the member, but if members get deleted those numbers get wrong. There's also a problem with member validations. For example two members register on the board but only the second member passes the email validation while the first member gets deleted after some time. This causes that one number is skipped. If every member number would be saved independently in the database, this problem could be circumvented. It would be easily possible to correct the numbers by recounting all current members while giving everyone a new number according to their registration date.
outlaw Posted December 31, 2004 Posted December 31, 2004 Nothing that can be done about it. If it was done in terms of just 1,2,3,4,5,6,7,8,9,10 and when 10 is deleted the next member gets it, any posts #10 made become the new 10, along with screwing up other parts in IPB not to mention modifications. It is not easy to recount the member data as you're looking at 5-10 queries per a member. So lets assume you have 50,000 members and the best case of 5 queries. 250,000 queries to recount everything, or 500,000 worst case. Grant this isn't counting the boards with 100,000 and more members.
Logan Posted December 31, 2004 Posted December 31, 2004 I liked how Hancoque explained it, sounded good and would be a useful feature. Then outlaw explained it "correctly" , and how its impossible to do. Doesn't sound good anymore. :P
Germany Posted December 31, 2004 Posted December 31, 2004 Yeah, I see no point and it does seem to be too much trouble.
Hancoque Posted January 3, 2005 Posted January 3, 2005 outlaw understood me wrong. It's just an added piece of information about the user. Each user account then also holds the member number, which can differ from the member's cell ID in the database. Recounting members in the ACP will then also reassign the proper member numbers. This isn't done while the board is normally running. If there are many members, recounting can be split into several single script runs, just like it works with reassigning the proper poster names, if there occured name changes (for instance process only 500 member number reassignments at a time). If a new member registers he gets a member number that is one number higher than the current member count instead of just reusing the next available cell ID. (Older) modifications would have no problem with such an implementation because they rely on the cell ID which is still present. They should only be updated to show the real number, saved for the member, but they wouldn't stop working. So, it's all just an additional table cell that holds the member number, not more and not less. An example: John Smith registers on the board and is the 10th member. Until now no member didn't pass the validation and no member was deleted. So John has a cell ID of 10 and is also shown correctly as the 10th user. The member count of the board is also 10. Now member number 5 gets deleted. This member had the cell ID 5. The member count gets updated and correctly shows 9 members. current situation: Now there's no member number 5 and there will never be one again. The board has 9 members but the last one is called member number 10. That doesn't fit. suggested situation: Imagine the same situation as stated above but with the difference that each member has a seperate and redundant member number information. After member number 5 got deleted the admin recounted the members to show the proper stats. In that case all members above 5 (6-10) get a new member number assigned while their cell IDs remain the same. Let's come back to John Smith. He still has the same cell ID as he had before the member deletion, but his member number information was updated and now shows correctly as 9. The same applies to the former members 6 to 9 who now show as members 5 to 8. All that is done here is to store a redundant piece of information (the member number) for each member that can be easily updated without touching any cell IDs, post and topic information and so on. You see, that this is just an addition and no replacement. That's why all older modifications stay intact.
outlaw Posted January 4, 2005 Posted January 4, 2005 What you want would be adding unneeded code for a feature that would be worthless for the fact that it just looks better.
Hancoque Posted January 4, 2005 Posted January 4, 2005 Then what is the purpose of having wrong member numbers?
Antony Posted January 4, 2005 Posted January 4, 2005 Why Bother with this, does anyone care if they are User ID 10 or 1000? Thier are many more important Features to work on than this in my Opinion.
outlaw Posted January 4, 2005 Posted January 4, 2005 Then what is the purpose of having wrong member numbers?<{POST_SNAPBACK}> Un-needed code. Un-needed info stored. Un-needed work. It's JUST a member id, it's not like it's maybe a issue with a table color of a member username, or something like the username replacing "A" with "MOO".
Antony Posted January 4, 2005 Posted January 4, 2005 ~Acctually, your Displaying incorrect Member information by the System Suggested, the Second member is still the Second Member who Registered. He was not the first. If the First Deletes his Account, that DOESNT mean he didnt Register. so therefore the Second member is STILL the second member.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.