PROPOSAL: read-only column array in config

[JerryNixon]

Allow the user to manually identify which columns are read-only, either because the user does not have METADATA access to allow DAB to query & derive this characteristic, and/or because the column is a Computed column, a Rowversion column, a Timestamp column, or one resulting from different Join or Union operations.

Note: this behavior would not change the special handling of IDENTITY columns.

Exclude is not a great solution

If we use Exclude for these columns, it means those columns are unavailable in the Get operation.

Goals

It is extremely undesirable to have different models for read and write operations. Identifying the read-only columns manually allows the consumer to receive a payload with all properties and post/put/patch the same payload with the same properties. This is accomplished because the config provides DAB with sufficient information to ignore those columns during write ops.

Underlying reasons

It is a significant pain point to have to modify a model's properties (in .NET) between read and write operations. This is because POCO or DTO objects are predefined types in .NET whose structure is not mutable in any practical sense of the work. To accommodate the current DAB requirements, a dynamic object or directly editing the JSON payload before http operations is required. All of these approaches work, but spoil the "saves you time and code" value-proposition of DAB to .NET developers.

Compat

Expressing the read-only columns in the config, will not reduce any existing functionality and is only additive to the config. Also, this should be completely backwards compatible.

This resolves several usability issues, including #1453.

Behavior

If a field is indicated as read-only all of the read ops would be unaffected by this. However, all the insert, update, and upsert ops would never attempt to write to that field(s). It also means that including that field(s) in the payload would not result in an error because the engine has sufficient information to ignore it. Again, this means the read and write ops could have the same payloads, meaning the consumer does not need to have multiple schemas/models or manipulate the structure of inbound models before sending them as outbound payloads to DAB.

Sample usage

Endgame

This gets us closer to this ideal/simple .NET usage scenario.

This is not possible today for two reasons:

1. The Id field (if identity) must be removed from the model before Patch.
2. Any read-only field must be removed from the model before Patch.
3. The DAB return type for read ops is a generic root with a value array.

This proposal addresses only number 2, allowing read-only properties in the payload if identified in the config.