I convert the email address to lowercase as the first action in the SC file. So when someone signs up, the email stored is lowercase. And when someone logs in, the email they enter is converted to lowercase before it's checked with the database.
2 Likes
But he has a point when he talks about the validate step:
If A != a then, it has sense to have a case sensitive toggle.
The first thing that appears on the mind is:
- Check if email exist
- If not, action.
So it doesn't sound so crazy for me one checkbox that also reminds that A != a
If the email address is always converted to lower case before being stored or queried then you shouldn't have an issue with duplicate records.
If your existing data contains multiple records of the same email with different cases then you'll need to address that first.
That's true, but you're talking about insert/query and forgetting the validate data which is the previous step, that will return another result if you don't apply the same, and I personally share the same thought.
For a new Wappler user, it's okay to think, "ok, I should convert to lower case both login/signup"
But honestly I think someone new can forget about applying .lowercase() on validate data step first (maybe he think that mail@mail.com == Mail@mail.com) so that's why he think a case sensitive toggle should be fine...
Maybe the best is to see which tutorial he refeers, so a .lowercase() can be added on the validate step part as well.
And also in this example:
Check if a Database Record Already Exists Before Inserting a New Entry
Hi Franse, thanks for your help.
I did add .lowercase() to my validation and input fields and it works beautifully.
Yes exactly ^ This is the point I was trying to make. I think many new users (like me) would have the 'incorrect' expectation that the "Does not exist in database" validation would not be case sensitive. I have some experience coding (not a lot), but I didn't realise this until I mistakenly added a duplicate account when testing haha.
The guide I am referring to is this one: