On Tue, Sep 16, 2014 at 7:59 PM, William Reade <william.re...@canonical.com> wrote: > On Thu, Sep 11, 2014 at 3:35 PM, Nate Finch <nate.fi...@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@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
