Open Stack

On 6/15/15 6:37 PM, Mike Bayer wrote:
>
>
> On 6/15/15 4:21 PM, Andrew Laski wrote:
>
> If I had to visualize what an approach looks like that does this 
> somewhat cleanly, other than just putting off contract until the API 
> has naturally moved beyond it, it would involve a fixed and structured 
> source of truth about the specific changes we care about, such as a 
> versioning table or other data table indicating specific "remove()" 
> directives we're checking for, and the application would be organized 
> such that it can always get to this information from an 
> in-memory-cached source before it makes decisions about queries. The 
> information would need to support being pushed in from the outside 
> such as via a message queue. This would still not protect against 
> operations currently in progress failing but at least would prevent 
> future operations from failing a first time.
>

Or, what I was thinking earlier before I focused too deeply on this 
whole thing, you basically get all running applications to no longer 
talk to the to-be-removed structures at all first, *then* do the contract.

That is, you're on version L.   You've done your expand, you're running 
the multi-schema version of the model.  All your data is migrated.    
Now some config flag or something else changes somewhere (still need to 
work out this part), which says, "we're done with all the removed() 
columns".   All the apps ultimately get restarted with this new flag in 
place - the whole thing is now running without including removed() 
columns in the model (they're still there in the source code, but as I 
illustrated earlier, some conditional logic has prevented them from 
actually being part of the model on this new run).

*Then* you run the contract.     Then you don't have to worry about 
runtime failures or tracking specific columns or any of that. There's 
just some kind of state that indicates, "ready for L contract".   It's 
still something of a "version" but it is local to a single version of 
the software; instead of waiting for a full upgrade from version L to M, 
you have this internal state that can somehow move from L(m) to L(c).    
That is a lot more doable and sane than trying to guess at startup / 
runtime what columns are being yanked.