-
-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Add options to disable collation and transform email and username to lower case #8767
Conversation
Thanks for opening this pull request! |
Failing test is:
|
@mtrezza sorry about that. Fixed. |
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## alpha #8767 +/- ##
==========================================
+ Coverage 94.29% 94.31% +0.02%
==========================================
Files 186 186
Lines 14785 14794 +9
==========================================
+ Hits 13941 13953 +12
+ Misses 844 841 -3
☔ View full report in Codecov by Sentry. |
@@ -533,6 +539,12 @@ module.exports.ParseServerOptions = { | |||
help: 'Starts the liveQuery server', | |||
action: parsers.booleanParser, | |||
}, | |||
transformEmailAndUsernameToLowerCase: { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure whether it's good to combine this into 1 option. It may be beneficial (for other use cases) to introduce 2 separate options that allow developers to control that for email and username separately. Also because by RFC specification, the email address "[email protected]" is not the same email box as "[email protected]".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mtrezza I think in this context it only makes sense to disable the 2 together, in case a database engine does not support collation.
These 2 are the only fields with case sensitive indexes, so for the problem we're trying to solve here, it only makes sense to have them as a "package deal".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand, but these options will live throughout Parse Server, not just for this specific use case. So this "package deal" may be a "no deal" for other use cases. If we decide to divide them into separate options later on it will be a breaking change and more complicated, so I'd suggest to separate them now. A simple use case may be a DB engine that does support collation but the developer wants all emails to be converted to lower case, but not for usernames, or vice-versa.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree with @Moumouls here. This PR is intended to solve a specific problem that at least 2 database engines that we know of suffer from, and not theoretical problems that may or may not happen in the future.
If we want to speculate on what may happen in the future, in my opinion it is much more likely that these database engines will eventually end up supporting collation, and these options can be removed after.
If the developer wants to convert all emails to lowercase, he already has tools on his hand to do so, that doesn't require a separate Parse Server option setting. That is a use-case specific scenario, and should not be the concern of Parse Server.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes need to be considered from a broader perspective, not just for a single use-case. We have seen this over and over again in the past where combined features need to be divided, causing breaking changes which we generally want to avoid. Converting only emails or only usernames to lowercase are valid use cases. The time spent in this conversation is more than would have been needed to split the single option into 2, which takes maybe 5 minutes. If this is more work or more complex then let's merge as a single option, but if it really just takes 5 mins, saving us potential future work for deprecation, etc, then I'd suggest to split this option.
describe('DatabaseController', function () { | ||
describe('validateQuery', function () { | ||
it('should not restructure simple cases of SERVER-13732', done => { | ||
describe('DatabaseController', () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are these changes related to this PR? If not, please revert. They are all over the PR, please check all changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens if an existing deployment with existing data with a DB that support collation has the transform email and username option suddenly turned on - is that possible? For example, say a DB has emails in different casings and the developer wants to only store emails in lowercase going forward, can they turn on that option and do a manual data correction for the existing data?
@b10f Would you want to get this ready for merge? I think this is almost done, I would just separate the two options as suggested above and remove the lint changes. |
Hello @b10f , I hope you're doing well. I wanted to thank you for the great work you've done on this PR. Given its significance and the time that has elapsed, could you find a moment to implement the feedback from @mtrezza ? If you need a hand or if you're pressed for time, please let me know so I can assist with a new PR to complete what you've started. Many thanks for your dedication! |
@mattia1208 please do so if you have time, unfortunately I won't be able to get around this in the forseable future |
Hi @mtrezza
If a developer wants to use this PR on an existing server, the developer need to migrate existing data and then activate the option. |
Hi @mtrezza, |
@mattia1208 see #8767 (comment); if @b10f doesn't have the resources to finalize this PR, then please feel free to open a new PR and split the options, then we can go ahead and merge. Alternatively, @b10f may be willing to give you access to their repository, so you can directly make the changes on this branch, which would be less work. |
@b10f may we eventually intervene in your repo so that we can fix these conversations without having to create a new pr in case you don't have time to get it done yourself according to @mtrezza requests? |
Agree; and again, if splitting this option into 2 is a lot of work, then let's merge as is; but if this is really just a 5 mins effort, then these 5 mins will likely save us much more time in the future. |
Continued in #8805 |
Pull Request
Issue
Add options to support MongoDB Serverless and AWS DocumentDB which currently does not have collation support.
Closes: #7937
Approach
Add 2 abstract options
disableCollation
andtransformEmailAndUsernameToLowerCase
to allow a developer to disable default collations of Parse Server and transformEmailAndUsernameToLowerCase to keep clean usernames and emails in the database.Tasks