Schemas API and other databases discussion.

[drew-gross]

As we work on Database adapters, some important questions around how we plan for future features need to be answered. Here are some features I have in mind:

Private fields. These fields would be readable and writable only by the master key and/or specified users. Storage for whether or not a field is private should go into the schemas API.

Field validations. A field can be marked as "not null" or "must be an email address" or "must be a number between 9 and 37, and also must be odd" or "must pass this cloud code function". This should also go into the schemas API.

Indexes. Adding indexes via API would enable some awesome dashboard features and should go into the API.

So, there are a few different models for how we should make the database adapters work.

Extreme Option 1: We require the database adapter to understand all portions of the schemas API. This means we can safely tell the database adapter to index a field or fields and know that it has either been indexed, or couldn't be indexed, because the update threw an error. Big downside: for features like Private Fields, that are only understood by Parse Server, adding the feature requires the database adapter to be upgraded.

Extreme Option 2: Database adapters are expected to store the schema as an opaque blob and have no understanding of it. This means we can add any features at any time, but database adapter can't use any of the information in the schema. Index feature is impossible, all objects are now just stored as JSON blobs because the adapter doesn't understand field types. Very silly.

Middle option 1: Database adapters are allowed to look at the schema, and are expected to error if it understands some parts and knows it can't fulfill them (eg. mongo adapter with two geo indexes) and if there are parts it doesn't understand, it's expected to store and return them. This allows us to add features like private fields and pointer permissions without needing to upgrade database adapters, and allows database adapter to look at the eventual field validations part of the API to do things like change the column type if it sees a "max length is 128 bytes" validation on a string field. The downside is that it makes it harder to add features like indexes that require database adapter support to truly work.

Middle option 2: We create some way of separating the fields that we demand the database adapter to understand and the fields we allow it to simply store without understanding. Then we can add features like private fields and pointer permissions without requiring changes to the database adapter, are able to trust that indexes are created if we tell the database adapter to create an index, and let the database adapter check out field validations if it wants to. Downside is that it's substantially more complicated.

Other options: taking suggestions! What do you think?

cc @flovilmart @gfosco @nlutsenko

[franzsilva]

*Hello Drew.
*
What would you consider to be the best way to move schemas between dev machines?.

If i updated my schema on my machine. How could i store that info to git so the other developer can see the changes.

Thank you

[drew-gross]

Currently there is no great way to store that info in git. One thing I can think of is to have a deploy script that uses the schemas API to check what existing schemas look like, compare with the schema in your git repo, then make the necessary changes. Thats one thing I'd like to improve later down the line.

[trondwh]

@drew-gross any more thoughts on Private fields?

I'm in process of moving a beta app off Parse and onto Parse Server, and making it more secure and production ready. It seems like the lack of Private fields is quite counterproductive to the object centric and easy and cached client side querying.

On one hand, designing a class structure with classes like UserPublic in addition to a private User class gets slightly messy, while moving all querying to Cloud Code makes you lose the easy caching and client SDK usage.

Any thoughts on this?

It seems like many experienced Parse developers tend to move everything into Cloud Code, and perhaps that is the way to go production quality.

Nevertheless, making it possible to have private fields seems to align well with the design of Parse.

I guess another possibility would be to add support for some sort of Parse.Cloud.filter(class, function) hook to Cloud Code.

[RafaRuiz]

Any update in this?

This is what I'm looking for since long time ago.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.