Skip to content
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

Closed
wants to merge 7 commits into from

Conversation

b10f
Copy link

@b10f b10f commented Sep 28, 2023

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 and transformEmailAndUsernameToLowerCase to allow a developer to disable default collations of Parse Server and transformEmailAndUsernameToLowerCase to keep clean usernames and emails in the database.

Tasks

  • Add tests
  • Add changes to documentation (guides, repository pages, code comments)
  • Add security check

@parse-github-assistant
Copy link

parse-github-assistant bot commented Sep 28, 2023

Thanks for opening this pull request!

@b10f
Copy link
Author

b10f commented Sep 29, 2023

This PR is based on #8042

Original author: @Moumouls

@mtrezza
Copy link
Member

mtrezza commented Sep 29, 2023

Failing test is:

1) DatabaseController transformEmailAndUsernameToLowerCase should not find a case insensitive user by username or email with transformEmailAndUsernameToLowerCase
  - Error: This user is not allowed to query email on class _User

@b10f
Copy link
Author

b10f commented Oct 2, 2023

@mtrezza sorry about that. Fixed.

@codecov
Copy link

codecov bot commented Oct 2, 2023

Codecov Report

Attention: 4 lines in your changes are missing coverage. Please review.

Comparison is base (80b987d) 94.29% compared to head (84f94ff) 94.31%.

❗ Current head 84f94ff differs from pull request most recent head c8782d8. Consider uploading reports for the commit c8782d8 to get more accurate results

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     
Files Coverage Δ
src/Options/Definitions.js 100.00% <ø> (ø)
src/Options/index.js 100.00% <ø> (ø)
src/Controllers/DatabaseController.js 94.05% <73.33%> (+0.07%) ⬆️

... and 2 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

src/Options/Definitions.js Show resolved Hide resolved
src/Options/Definitions.js Show resolved Hide resolved
src/Options/Definitions.js Show resolved Hide resolved
@@ -533,6 +539,12 @@ module.exports.ParseServerOptions = {
help: 'Starts the liveQuery server',
action: parsers.booleanParser,
},
transformEmailAndUsernameToLowerCase: {
Copy link
Member

@mtrezza mtrezza Oct 3, 2023

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]".

Copy link
Author

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".

Copy link
Member

@mtrezza mtrezza Oct 3, 2023

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @mtrezza @b10f , following YAGNI and KISS, currently there is no a real need to split the option. As @b10f it's really specific to DBs not supporting collation. Here i'm in favor to the bundle, and if someone need separate usage it could be a another PR.

Copy link
Author

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.

Copy link
Member

@mtrezza mtrezza Nov 8, 2023

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', () => {
Copy link
Member

@mtrezza mtrezza Oct 3, 2023

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.

Copy link
Member

@mtrezza mtrezza left a 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?

src/Options/Definitions.js Show resolved Hide resolved
@mtrezza
Copy link
Member

mtrezza commented Oct 18, 2023

@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.

@mattia1208
Copy link
Contributor

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!

@b10f
Copy link
Author

b10f commented Nov 3, 2023

@mattia1208 please do so if you have time, unfortunately I won't be able to get around this in the forseable future

@Moumouls
Copy link
Member

Moumouls commented Nov 4, 2023

Hi @mtrezza

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?

If a developer wants to use this PR on an existing server, the developer need to migrate existing data and then activate the option.

@mattia1208
Copy link
Contributor

Hi @mtrezza,
so how shall we procede?
Should we close the current conversations and therefore proceed with the merge or should I still create a new pull request?
Given, as stated by @b10f , that this problem, if solved, would be beneficial to any developer who wants to run parse in a serverless environment. It would be great if this change could be added to the Parse Server 7 alpha in time!

@mtrezza
Copy link
Member

mtrezza commented Nov 8, 2023

@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.

@Sbef98
Copy link

Sbef98 commented Nov 8, 2023

@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?
We see both your points, and in my opinion both are valid, but at the same time both are blocking this update that would be considered quite nice by a lot of people for quite small details (or at least they look so compared to the usefulness of this update!)

@mtrezza
Copy link
Member

mtrezza commented Nov 8, 2023

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.

@mattia1208
Copy link
Contributor

@mtrezza new PR #8805

@mtrezza
Copy link
Member

mtrezza commented Nov 14, 2023

Continued in #8805

@mtrezza mtrezza closed this Nov 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Parser Server not fully compatible with Mongo Atlas Serverless
5 participants