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

immutable keyword #31

Open
silverwind opened this issue Jun 17, 2020 · 3 comments
Open

immutable keyword #31

silverwind opened this issue Jun 17, 2020 · 3 comments

Comments

@silverwind
Copy link

silverwind commented Jun 17, 2020

JSON schema has readOnly and writeOnly to specify static read/write access to a property but sometimes it's useful to have immutable properties that can only be written once and only read thereafter.

For example a POST request could accept a value (property acts writeOnly) and for subsequent request the property acts readOnly similar to immutable variables in many programming languages.

I think a immutable keyword would be a useful meta-data addition that validators can generally ignore unless they have knowledge whether the validated data is considered "new" in which case it could fail validation when it's not new and a value for an immutable property is present.

@karolzlot
Copy link

karolzlot commented May 10, 2022

I think readOnly is exactly for this use case (to mark field in API to which client can't write to, so it's immutable field).

You just need to have more than one schema. E.g. one for creating entity, and second for getting it and updating it. (I think schema for getting and updating can be usually the same)

@gregsdennis
Copy link
Member

Additionally, you can also mark an object as read-only.

{
  "type": "object",
  "properties": {
    ...
  },
  "readOnly": true
}

This, to me, says that the entire object is immutable.

Since readOnly is an annotation only, it's the application's responsibility to enforce it, whether it's on a property or the object.

@dchandekstark
Copy link

I am sympathetic to this issue, although I'm not sure what the right solution is. The problem IMO is that writeOnly defines a property that cannot be retrieved. The semantics just feel counterintuitive. It appears that the only way -- with a single schema -- to make a property once-writable and retrievable (like setting the value of a primary key in a RDBMS table) is to define the property as readOnly, and that also feels weird, since the client should then have no expectation that the value is settable, and the application has to know, separately from the schema, what the real semantics are in any case. 🤷

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

No branches or pull requests

4 participants