Open Stack

On 09/01/2016 08:29 AM, Henry Nash wrote:
>
> From a purely keystone perspective, my gut feeling is that actually the
> trigger approach is likely to lead to a more robust, not less, solution - due
> to the fact that we solve the very specific problems of a given migration
> (i.e. need to keep column A in sync with Column B) or a short period of time,
> right at the point of pain, with well established techniques - albeit they be
> complex ones that need experienced coders in those techniques.

this is really the same philosophy I'm going for, that is, make a schema 
migration, then accompany it by a data migration, and then you're done. 
The rest of the world need not be concerned.

It's not as much about "triggers" as it is, "handle the data difference 
on the write side, not the read side".  That is, writing data to a SQL 
database is squeezed through exactly three very boring forms of 
statement, the INSERT, UPDATE, and DELETE.   These are easy to intercept 
in the database, and since we use an abstraction like SQLAlchemy they 
are easy to intercept in the application layer too (foreshadowing....). 
   When you put it on the read side, reading is of course (mostly) 
through just one statement, the SELECT, but it is a crazy beast in 
practice and it is all over the place in an unlimited number of forms.

If you can get your migrations to be, hey, we can just read JSON records 
from version 1.0 of the service and pump them into version 2.0, then 
you're doing read-side, but you've solved the problem at the service 
layer.  This only works for those situations where it "works", and the 
dual-layer service architecture has to be feasibly present as well.