IZIVIA/ocpi-toolkit

Question: Should we avoid having Partial field inside Partial object

Opened this issue · 3 comments

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.

Yes I think you are right, I recoded generation logic here: #31, and I can make the changes you are requesting there

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