State should not depend on the API server

[David Cheney]

On Tue, Sep 16, 2014 at 7:59 PM, 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.
>
>> 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.

For example, apiserver/params.StateServingInfo was being stored
directly in the database. Woe to the person that updates the api only
to discover that data was silently deleted from the state database :(

>
>> Separation of logic is absolutely a good thing.  Separation of data is not
>> nearly so useful.
>
> It's harder than you might think to separate the data from the logic
> that acts on it ;).
>
> Cheers
> William
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev