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
As far as I can see, all generated Partials, use Partials as field values. For example SessionPartial.charging_periods is of type List<ChargingPeriodPartial>?, but the expectation is that we provide a valid ChargingPeriod, not partially updating existing ChargingPeriods (as that would require a PUT Session call)
When a PATCH request contains the charging_periods field (inside a Session object), this SHALL be processed as a request to add all the ChargingPeriod objects to the existing Session object.
The issue is worse with the Location object, where we have about 10+ fields that are complex objects. Unless I interpret the protocol incorrectly, only the provided root object can be Partial, while all field values should be "regular" fully valid objects. Therefore types like GeoLocation and BusinessDetail don't even need to be annotated as @Partial, and generated Partials should not use Partial fields as field types. Which means a LocationPartial should contain a list of Evse, and only when calling PATCH Evse endpoint should we using EvsePartial, etc.
The text was updated successfully, but these errors were encountered:
The spec is not super clear on that, for me it would make sense to only update latitude of a Location for instance. I will try to get more information about that. Maybe there are some exceptions, like the one you stated about ChargingPeriod.
it looks like "it depends" on how one interprets the protocol ... I would have assumed that a change to an evse will always use the PATCH evse endpoint, but apparently that is not common consensus given how the creator of this issue experienced a partner wanting to use the PATCH location endpoint with a wonky json: ocpi/ocpi#285
assuming you have any impact on the partners implementation of the PATCH endpoint, and can make them only send PATCH for root element, no need for nested Partials ... on the other hand, if you need to be able to consume a crazy json merge object like the one in 285, you'd need nested Partials
As far as I can see, all generated Partials, use Partials as field values. For example
SessionPartial.charging_periods
is of typeList<ChargingPeriodPartial>?
, but the expectation is that we provide a valid ChargingPeriod, not partially updating existing ChargingPeriods (as that would require a PUT Session call)The issue is worse with the Location object, where we have about 10+ fields that are complex objects. Unless I interpret the protocol incorrectly, only the provided root object can be Partial, while all field values should be "regular" fully valid objects. Therefore types like
GeoLocation
andBusinessDetail
don't even need to be annotated as@Partial
, and generated Partials should not use Partial fields as field types. Which means a LocationPartial should contain a list of Evse, and only when calling PATCH Evse endpoint should we using EvsePartial, etc.The text was updated successfully, but these errors were encountered: