Disable case-insensitive index on _User

[EraserKing]

New Feature / Enhancement Checklist

• I am not disclosing a vulnerability.
• I am not just asking a question.
• I have searched through existing issues.

Current Limitation

Currently while Parse Server is starting up, on MongoDB, it tries to create a few indexes with case-sensitive on, on collection _User.

However not all MongoDB supports case-sensitive, for example, Azure Cosmos DB for Mongo does not support: Supported Indexes. This leads to Parse Server connecting to such database directly fails to start.

Feature / Enhancement Description

With switches of options / environment toggled on, skipping validating / creating such indexes. I see the options in PR #5634 but I don't know why that's not implemented finally.

Example Use Case

1. Add switches in options (just like PR Case insensitive signup #5634)
2. Check the switches in Controllers - DatabaseController - performInitialization method
3. Skip some calls to ensureIndex when the switches in options are turned on

Alternatives / Workarounds

No. We cannot create case-insensitive indexes on Azure Cosmos DB and we cannot disable creating such indexes in Parse. Totally not working.

3rd Party References

Not necessary.

[parse-github-assistant]

Thanks for opening this issue!

• 🎉 We are excited about your ideas for improvement!

[EraserKing]

Additionally, the current code also tries to create an index on '_Idempotency' with 'ttl' set to 0 on 'expire' field when running against MongoDB. This behavior is forbidden on Azure Cosmos DB for MongoDB because (1) it force the field to be an reserved field '_ts' other than some custom field, and (2) it enforces the value of 'ttl' to be larger than 0.
See Azure Document

Not sure why the current code set 'ttl' to 0 when using MongoDB - I checked the document and found it says the value should also be positive non-zero value (just like Azure document says) See MongoDB Document

So, here in the PR I just skips adding such index and I think it would not be an issue, since setting it to 0 doesn't automatically delete the expired records.

[mtrezza]

• You are bringing up some things that should probably be addressed individually, rather than broadly disabling them with a "compatibility" option for Cosmos DB.
• A "compatibility" option is rather generic - compatible with what version? A future version of Cosmos DB may start / end support for different features. So we may need a different concept than just a single boolean option. Disabling / modifying the behavior should be implemented DB neutral where possible; so instead of adding one specific "compatibleWithCosmosDb" option that changes 3 behaviors, we may rather implement 3 options that individually change each of the behaviors.
• Depending on the level of compatibility we may need a new adapter rather than "hacking" the MongoDB adapter, but I haven't looked into that much yet, so I couldn't tell.

[EraserKing]

• I was thinking if some separate switches would be better and in my local testing initially I was doing in that way, but later I think normally on a standard MongoDB implementation seems there's no need to disable "ensure" the indexes partially instead of all.
• I have done some research and for the all four versions of API which Azure provides right now, they're all having the same restrictions (case-insensitive and ttl).
• I have done some testing on the features used in my app with this Azure-edition MongoDB database, and so far I think the rest features are compatible, so I guess some special switches would be enough instead of a completely new adaptor - at least to me 99% code is still working.
• About the suggestion you mentioned in the PR about moving options into MongoDB adaptor, I agree with it.

In a conclusion, I'll tweak my code to be (a) having three switches on these three indexes, and (b) moving these switches to MongoDB node other than in the root node.

[Moumouls]

@EraserKing @mtrezza may be related #8042

[mtrezza]

I have done some research and for the all four versions of API which Azure provides right now, they're all having the same restrictions (case-insensitive and ttl).

Yes, but we can't tell if that changes in the future.

[EraserKing]

Thanks. It's the partiallly the same. For case-sensitive, my change looks the same as that PR. But to play it on Azure Cosmos, another change (TTL on expiry) is also necessary because Azure Cosmos requires TTL to be set on an internal field other than the custom field.

[Moumouls]

@EraserKing and @mtrezza , I'll try to explore quickly if we can here just introduce a hook function instead of many little boolean. I'm not sure if it's the correct strategy in the long term since many ecosystems exists, and parse server itself will not be able to fulfill each one by default. So an inversion of control is maybe the right solution.

[lilonpro]

@EraserKing @mtrezza may be related #8042

Seems it is not fixing this issue, I ran the PR with the env set still getting the same error.

[EraserKing]

@lilonpro Not sure which PR you mean
if you mean #8042, that's only a part for Azure Cosmos; there's a TTL index which needs to be disabled too
If you mean #8494, I can confirm when I made that PR it's working for Azure Cosmos, but I haven't tried recently since then

[lilonpro]

@EraserKing What env bar did you set? Do you mind share?

[EraserKing]

@EraserKing What env bar did you set? Do you mind share?

/* Disables behavior to ensure case-insensitive index on field username on _User collection. Set to true if using a database not supporting case-insensitive indexes.
:DEFAULT: false /
disableEnsureUsernameCaseInsensitiveIndex: ?boolean;
/ Disables behavior to ensure case-insensitive index on field email on _User collection. Set to true if using a database not supporting case-insensitive indexes.
:DEFAULT: false /
disableEnsureEmailCaseInsensitiveIndex: ?boolean;
/ Disables behavior to ensure time to live index on field expire on _Idempotency collection. Set to true if using a database not supporting TTL index on this field.
:DEFAULT: false */
disableEnsureIdempotencyExpireIndex: ?boolean;