3 ms·
> then we add the ability for users to update their email. At this point, you should verify the new email. At least until it is verified, you must track the ol
by knallfrosch 2y ago
> then we add the ability for users to update their email.
At this point, you should verify the new email. At least until it is verified, you must track the old email. At this point, you realize you can now introduce a synthetic key and you're fine.
Let's say you have a duplicate customer entry and the customer demands their accounts be merged. Now you can't identify the user by their key alone, since by definition, they can't be the same (yet.)
- epcoa 2y ago> At this point, you realize you can now introduce a synthetic key and you're fine. Except for having to update all foreign references. Some of those may be external further complicating issues. Emails are often among the worst keys because they are not terribly stable and they are reusable often enough to burn you.
- jrs235 2y agoAlso are emails case sensitive or not? In some systems (that you don't control mind you) they are and others they are not...
- sgarland 2y agoPer RFC5321, the local part (before @) _may_ be case-sensitive, but in practice, it almost never is, and relying on case sensitivity is a recipe for disaster. The domain must always be case-insensitive.
- jrs235 2y agoMy point being is if you're using email as a key you "have to" treat it as case sensitive even though for most it's not. And yes, I agree it will be a recipe for disaster.