[Engine-devel] Logical network Usages collection problematic approach

[Eoghan Glynn]

> >> The new design of logical network 'usages' collection came out a
> >> bit
> >> problematic or shall i say annoying.
> >> The idea is to send the entire collection elements every time a
> >> user
> >> wants to update a single usage otherwise the missing elements will
> >> be
> >> automatically removed from the collection.
> >>
> >> Example:
> >> having <usages><usage>VM</usage><usages>
> >> 1. in order to add 'display' usage to the collection i must send
> >> 'vm'
> >> as well.
> >> 2. to remove an element from the collection, i must send the
> >> entire
> >> collection without the desired element
> >> (note: in this case it is only one extra element for every update
> >> but
> >> in other cases it could be much more)
> >
> >
> >Yep, this seems to conflict with the general idiom around the
> >interpretation of missing properties in a PUT representation -
> >i.e. any properties omitted from the representation are ignored
> >and not changed.
> >
> 
> **I'm going to explain the current modelling; this does not mean I
> object to other modellings**
> 
> In the current modelling, usages are a non-trivial collection within
> a
> Network, but they are not business entities, and thus do not have
> their
> own 'context' (i.e, there's no: .../networks/{network:id}/usages).

A-ha, I see. 

I was thrown by the overloading on the term "collection", which
I would have understood as a set of resources that may be addressed
as a group.

Whereas in fact we're more talking about an aspect of the Network
representation that happens to include boolean sub-elements, right?

In which case, making this explicit via your suggestion:

  <usages><vm>true</vm><display>false</display></usages>

would seem reasonable on the face of it.

However there's an implementation wrinkle in the type-mapper
framework ...

I'd understand the PUT below as meaning:

 "set the VM usage to true, and leave other usages as they are".

    GET .../networks/{network:id} HTTP/1.1

    200 OK
    <network id="{network:id}">
      ...
      <usages><display>true</display></usages>
    </network>

    --

    PUT .../networks/{network:id} HTTP/1.1
    <network id="{network:id}">
      <usages><vm>true</vm></usages>
    </network>

    200 OK
    <network id="{network:id}">
      ...
      <usages>
        <vm>true</vm>
        <display>true</display>
      </usages>
    </network>

as things currently stand, the type mapper called prior to the
UpdateNetwork action being initiated doesn't have access to the
*existing* network entity, so it has no way of setting the is_display
flag on the mapped entity to match the pre-existing setting.

I guess you could work around this by forcing a network lookup *prior*
to the update, so that the pre-existing display setting is available,
and then pass this entity as a template into the type mapping.

> >I wonder would a POST/DELETE idiom be more natural, if the individual
> >usages would be pressed into service as a psuedo-OID, e.g:
> >[snip]
> 
>   
> We'd need to develop an infrastructure for generating on-the-fly IDs
> for internal,
> non-entity, collections (based on a specified field)

Well, the idea was to avoid the need for generating on-the-fly OIDs,
by reusing the display "name" as the OID. But yes, it would still
involve some deviation from the established collection/sub-resource
implementation patterns.

Cheers,
Eoghan