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

Do not allow to protect default fields #6439

Merged

Conversation

BufferUnderflower
Copy link
Contributor

No description provided.

@davimacedo
Copy link
Member

I'm not sure. I think that protecting the default fields it will make the SDKs to fail. So I'm wondering if it is really a good idea to implement a feature in the server side knowing that the SDKs will fail if used. @dplewis or @acinader may have a different vision about this.

@codecov
Copy link

codecov bot commented Feb 25, 2020

Codecov Report

Merging #6439 into master will decrease coverage by 0.56%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #6439      +/-   ##
==========================================
- Coverage   93.96%   93.39%   -0.57%     
==========================================
  Files         169      169              
  Lines       11811    11811              
==========================================
- Hits        11098    11031      -67     
- Misses        713      780      +67
Impacted Files Coverage Δ
src/Controllers/SchemaController.js 96.91% <100%> (ø) ⬆️
...dapters/Cache/RedisCacheAdapter/KeyPromiseQueue.js 0% <0%> (-95.46%) ⬇️
src/Adapters/Cache/RedisCacheAdapter/index.js 14.28% <0%> (-83.68%) ⬇️
src/Routers/PushRouter.js 93.1% <0%> (-3.45%) ⬇️
src/Adapters/Storage/Mongo/MongoStorageAdapter.js 92.79% <0%> (-0.68%) ⬇️
src/RestWrite.js 93.64% <0%> (-0.17%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c7f96c9...61c00dc. Read the comment docs.

@BufferUnderflower
Copy link
Contributor Author

I'm not sure. I think that protecting the default fields it will make the SDKs to fail. So I'm wondering if it is really a good idea to implement a feature in the server side knowing that the SDKs will fail if used. @dplewis or @acinader may have a different vision about this.

Reasonable, I was working on dashboard and noticed 'field does not exist' error when tried to protect some of default fields.

So another solution would be to just fine tune that message and agree to disallow protecting default fields.

@BufferUnderflower BufferUnderflower changed the title Allow protect default fields Do not allow to protect default fields Feb 25, 2020
Copy link
Member

@davimacedo davimacedo left a comment

Choose a reason for hiding this comment

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

Looks good to me. LGTM!

@davimacedo davimacedo merged commit 6b0efae into parse-community:master Feb 28, 2020
UnderratedDev pushed a commit to UnderratedDev/parse-server that referenced this pull request Mar 21, 2020
* consider default columns

* disallow protecting default fields
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.

2 participants