You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 18, 2023. It is now read-only.
The use-case has been ambiguous, and ERT is mostly using it with ?realization_index=0 to work around the mess.
I propose we move the userdata field from Record to RecordInfo. The API will be the same.
For backward-compatibility, this endpoint should still accept realization_index, but if it is something other than 0 it return HTTP 422 Unprocessable Entity.
The text was updated successfully, but these errors were encountered:
This is the case where we stuff a list of records into one record with realisation index 0?
Not really. The issue being that only realization_index=0 holds the metadata for all the realizations which already makes it erroneous since when writing any realization record (with realization_index>0) thus expects that realization_index=0 exists. Therefore putting metadata into RecordInfo makes perfect sense.
Why be backwards compatible? Current ERT use is a hack that is, to my knowledge, not in use—except in testing.
Agree here. I would say we don't need to be backwards compatible as the API is still being developed...
The use-case has been ambiguous, and ERT is mostly using it with
?realization_index=0
to work around the mess.I propose we move the
userdata
field fromRecord
toRecordInfo
. The API will be the same.For backward-compatibility, this endpoint should still accept
realization_index
, but if it is something other than 0 it return HTTP 422 Unprocessable Entity.The text was updated successfully, but these errors were encountered: