When removing fields, which do not have a fallback, we can convert them to a generated function, to return a value.
mydeprecatedfield() {
return () => null;
}However the above looks a little verbose. And it only applies when using api.get.
Proposal:
A better solution might be to handle an explicit definition which would tell the processor to ignore requests to this field.
This could be used to prevent the field being referenced in all .get, .patch, .post and .delete operations, whether using the field in a filter, join, modification or fields requests.
The fields attributes would convert a null value to {deprecated: true} possibly. Rather than the more aggressive {readable: false, writeable: false} which trigger exceptions.
This should also be considered in light of an alternative, where the schema field definition for a model are exclusive of all other fields. However that could equally be handled with a default field, i.e. default:false field property.
When removing fields, which do not have a fallback, we can convert them to a generated function, to return a value.
However the above looks a little verbose. And it only applies when using
api.get.Proposal:
A better solution might be to handle an explicit definition which would tell the processor to ignore requests to this field.
mydeprecatedfield: nullThis could be used to prevent the field being referenced in all
.get,.patch,.postand.deleteoperations, whether using the field in a filter, join, modification or fields requests.The fields attributes would convert a
nullvalue to{deprecated: true}possibly. Rather than the more aggressive{readable: false, writeable: false}which trigger exceptions.This should also be considered in light of an alternative, where the schema field definition for a model are exclusive of all other fields. However that could equally be handled with a default field, i.e.
default:falsefield property.