-
-
Notifications
You must be signed in to change notification settings - Fork 4.8k
Add unique fields only capability to schema. #6059
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
Comments
Can you detail how the |
The option would simply ignore all universal system reserved fields(objectId, createdAt, updatedAt) as well as any additional system info. So, rather than returning this.
It would return this.
In other words it would return just the data thats allowed when doing a POST or PUT to the schema endpoint. Making things like automated schema deployment, transfering, or duplication much much simpler because you can use the data returned pretty much as-is. |
I think your issue is related to this one. But I am afraid that, even returning these fields, you will not be able to just push them to the schema API since Parse Server does not currently support changing existing fields. I think we should come up not only with an option in the existing API, but two new endpoints (pullSchema and pushSchema) that are specially designed for schema control and migration. Maybe we should also add two commands to the CLI as well. What do you think? @dplewis @acinader thoughts? |
That would add such great potential that goes way beyond even what I was hoping for. You know whats funny is that I think what you just suggested was the entire goal of schema when it was released. It's been a while but I remember an article on the parse homepage, we're talking even before Facebook bought Parse when schema was first announced that talked about a long term goal of wanting to appeal to SAAS and PAAS developers. I think it goes beyond that though and would make it easy to take Parse in the direction the rest of the industry is already going. More and more companies are using things like docker and kubernetes(same thing?) to do things like scale and deploy database instances rather than relying on massive database servers. pull and push schema would be a huge steps in writing easy scripts that do just that. If anyone has rails experience this could aid in writing automated rake-like migration scripts. Some day it may even be able to help us add the one feature everyones asked for since Parse went open source. An import/export database button on Dashboard. Sorry to drone on. By the way the main thing that has me asking here is because the Javascript SDK doesnt allow you to initialize a schema with a string period which is why I had to revert to using the rest endpoints. You think I should go suggest that over there? Let me know if you'd like any help. I work on the Parse iOS sdk and know my away around parse-server a fair bit. |
Nice! I think we should go for it. Its this something that you would be willed to tackle? I didn't understand the issue with the JS SDK, but I think it would be good you open the issue in its repo. |
In the Javascript SDK you can actually do lots of stuff to modify a schema. mySchema.addString('stringField') etc... However, there is no functionality to retrieve or initialize a classes schema data within the JS SDK. In other words there is no |
got it... I see that |
You could save if the schema being created was a new class for that server and not a new instance. Which is what I was needing. Taking a class from one server and creating/duplicating it on another server. |
For this case, wouldn't be better you call schema.save() individually for each new class you want to save? Or maybe Parse.Schema.create(listOfClassesToCreate) ? |
I was suggesting this because I think it would be easy. currently the Schema class on the JS SDK has the following.
Now I know you cant have two constructors but you could create a static function that basically accomplishes the following
Something super simple that you can hit up https://YOUR.PARSE-SERVER.HERE/parse/schemas/myClass and with the userFieldsOnly feature which removes the createdAt etcc... so you can just take the response as-is and do the following.
I do want to do multi class initializations. Unless I'm missing something though, single class creation from schema data should be pretty easy to do. What would also be pretty exiting about that is you could simply have a JSON file with an array of your class schemas. Then, when you kick off a new parse server environment, read that file, and loop and create all your classes with only a few lines of code and very little effort. Fast simple server duplication. |
Do you like to send a PR with this idea so we can better discuss? |
😊 I think this is an issue I would love to tackle as I am trying to get my hands around Parse. Maybe I should add a PR down already. |
@femolacaster That's great to hear! See our Contribution Guide for how to make a pull request, or read our New Contributor's Guide if this is your first time contributing. Mind that @fn-faisal already opened #7388, which may already address this issue. You could just look over the PR and the changes to see how far it is and whether you have any suggestions for improvement. |
Uh oh!
There was an error while loading. Please reload this page.
It would be really great if we could add like a uniqueFieldsOnly parameter to the schema rest functionality.
Recently I've been working in a more professional/complex deployment pipeline where I have a Production, Development, and local parse servers. This brought me to the schema endpoint for deploying structure changes down the pipeline. As you know doing a POST to the schema endpoint with anything that is reserved internally such as objectId, updatedAt, createdAt will return you an error making it impossible to simply take the data returned from a schema request on one parse instance and posting it to another. I was about to write a script to save me from removing these fields by hand and figured it may be worth discussing adding this feature to the server itself as I'm sure others deal with similar scenarios.
The text was updated successfully, but these errors were encountered: