State should not depend on the API server

[roger peppe]

On 16 September 2014 10:59, William Reade <william.reade at canonical.com> wrote:
> On Thu, Sep 11, 2014 at 3:35 PM, Nate Finch <nate.finch at canonical.com> wrote:
>> I don't see how having different identical structs that are updated
>> simultaneously in any way prevents any problems with compatibility.
>
> If we're updating those structs simultaneously, we're completely
> missing the point. Once we've defined a pure-data struct that might be
> persisted or sent over the wire we *must not change that struct* -- if
> we want to send or store different data, we need a new struct.

Agreed (well, modulo backwardly compatible additions).

>> Maybe I'm missing something from the proposal, but it seems like this just
>> adds busywork without actually solving any problems that weren't caused by
>> incorrect use of the code in the first place.
>
> Isn't that tautological? AFAICS, storing a charm.Meta (or a
> params.anything) directly in the DB *is* incorrect use of the code,
> but nobody realises that until it's too late: that is the problem, and
> that's what we're addressing.

I don't believe it's incorrect use of the code. You wanna store a charm.Meta
in the DB? Why not? It's just data - it's not really that different from storing
an int or a string in the DB. The problem comes when it *changes*.
That's when you might need a different version of the data structure
(hopefully only different in the old API versions, so compatibility
clutter is kept to a minimum in the latest version) and code to
convert between the two *on demand*.

I totally agree it's a problem that no-one realises until it's too late
(someone can change charm.Meta in the charm package in a backwardly
incompatible way, but we have no tests that fail when that happens).

That's why I have suggested writing an API compatibility checker. That
way, you won't be
able to make type-incompatible changes like that without causing the tests
to fail.

Then you can have your cake (simple marshaling of the obvious data
structures, avoiding unnecessary garbage generation) and eat it too
(avoid unintended API breakage).

  cheers,
    rog.