SimpleMachines
Add unique index to members table
I'm surprised this has never been done before, I imagine the related issue happens on 2.0 as well.
Hey @albertlast can you do a rebase against release-2.1 to merge this one. Thanks.
it's conflict free now, please had in mind, this pr expect that the data correct at point of time where upgrade step is running
Adding a unique index will force us to handle the error during user registration. Need to check if codewise we can handle it
Something feels very wrong here...
I swear this worked earlier. It wasn't done by DB, it was logically done somewhere. A few years ago there was discussion, & we looked into strengthening our existing duplication detection by trying to detect/prevent homographs. I.e., detect & prevent different chars that look alike but aren't... It feels like something has been lost somewhere along the line...
Yes, dupe detection does work today...
I think the real bug here is detecting & preventing that double-click scenario... The first one hadn't 'stuck' yet, so was ignored in the the existing duplicate check. (Which I haven't been able to duplicate...)
Has anybody duplicated the problem?
If nobody can reproduce this, we should close the issue & PR. We have existing methods to detect dupes.
One person seeing something once doesn't count. For all we know, the initial issue was caused by a faulty DB, e.g., a missing index.
We should only make this type of change if we know for certain it's needed...
In my test smf i got the issue too. So i would say the logic which exists doesn't work. Because it's expected that php run in single thread mode or so, So when parallel user get created the existing logic fails.
Sure, that can happen, thats why I wanted to know if codewise we can do something about it. The check is insufficient if we have no way to recover the error and gracefully display it to the user.
well the database would response with a unique index violation, in this moment the code could ask for new name or different mail address.
well the database would response with a unique index violation, in this moment the code could ask for new name or different mail address.
Do note, that in the case of a "double click" scenario, the first one would most probably be successful - so asking for another name or email could just create an endless loop of registrations, right?
why should be this endless? and otherhand we hand two different id_member with the same member_name.
why should be this endless? and otherhand we hand two different id_member with the same member_name.
Just thinking outloud here, but what I meant was something like this: Double click - > One successful registration -> Request new credentials -> Double click -> One successful registration -> Request new credentials -> Double click
since you need for all double click different username and mail address, i guess this is not a endloss loop.
Ok, I'm just saying we usually try our best to stop people from making multiple registrations at one go, and this could / would actually provide a means to do that.
This will cause upgrade failures if duplicates do exist because this query will fail and stop an upgrade.
It's too late to make this change in the 2.1.
However, if a new PR implementing these changes and the ones in #6208 is submitted for release-3.0, that would be worthwhile.
