On not copy-pasting state and params struct conversions

[William Reade]

On Tue, Feb 10, 2015 at 11:35 AM, Andrew Wilkins <
andrew.wilkins at canonical.com> wrote:
> Not sure I follow what you're saying about "in terms of the storage
types",
> so
> I'll describe how it is at the moment.
>
> The types are in three places:
>   - juju/juju/storage

...which contains the types that represent "how juju thinks about storage"
-- they're the actual model types.

>   - juju/juju/apiserver/params
>   - juju/juju/state

...which contain wire/db representations of the juju/juju/storage types to
insulate the wire/db formats from changes to the above.

> There's a storage.Volume, a params.Volume, and a state.Volume.
state.Volume
> is actually an interface, but there's a VolumeInfo which ~correlates to
the
> other
> struct types.
>
> I think the conversion from params<->state all needs to be in
> apiserver/<something>.

I don't think that's right -- surely a state.Volume's VolumeInfo should
actually be a storage.Volume? i.e. when the apiserver gets volume info over
the wire it converts it to a storage.Volume at the earliest opportunity,
and passes that into state where necessary, which only converts again when
it needs to serialise; and similarly, in the other direction, the apiserver
gets a storage.Volume directly out of state, and converts that to a
params.Volume on the way out. Considering that our business logic is
essentially smeared through state and apiserver, volume manipulation could
happen in either layer; and we want that behaviour associated with the
storage.Volume type, so we can move it between layers sanely; so we should
have something like:

           where               what
    ============================================
          <wire>            params.Volume
    -------------<convert here>-----------------
         apiserver          storage.Volume
    --------------------------------------------
          state             storage.Volume
    -------------<convert here>-----------------
           <db>             state.volumeDoc

> I could live with it, but I don't like the idea of adding dependencies to
> every domain
> for every facade that uses it.

I think we really do want domain dependencies in any part of the apiserver
that contains logic pertaining to that domain, even if the logic is simple
conversion [0]. Without that, domain logic just gets attached to whatever
type lies closest to hand and makes it harder to move it to the right place
as the code evolves.

Cheers
William

[0] obligatory: http://thecodelesscode.com/case/97
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20150211/378d4f61/attachment-0001.html>