Open Stack

On 08/30/2016 08:04 PM, Clint Byrum wrote:
>
> My direct experience with this was MySQL 5.0 and 5.1. They worked as
> documented, and no I don't think they've changed much since then.
>
> When they were actually installed into the schema and up to date with
> the code that expected them, and the debugging individual was aware of them, things were fine.
>
> However, every other imperative part of the code was asserted with git,
> package managers, ansible, puppet, pick your choice of thing that puts
> file on disk and restarts daemons. These things all have obvious entry
> points too. X is where wsgi starts running code. Y is where flask hands
> off to the app, etc. But triggers are special and go in the database at
> whatever time they go in. This means you lose all the benefit of all of
> the tools you're used to using to debug and operate on imperative code.

to use your phrasing, I'd characterize this as "an unnecessarily bleak 
view" of the use of triggers as a whole.  I've no doubt you worked with 
some horrible trigger code (just as I've worked with some horrible 
application code, but I've worked with horrible stored procedure / 
trigger stuff too).

The triggers that have been in play in the current Keystone proposals as 
well as the one we were working with in Neutron were simple one liners 
that essentially act as custom constraints - they check a condition then 
raise an error if it fails.  In particular, MySQL doesn't have support 
for CHECK constraints, so if you want to assert that values going into a 
row have some quality more exotic than "not null", you might have to use 
a trigger to get this effect.

Clearly, a trigger that is so complex that it is invoking a whole series 
of imperative steps is not a trigger any of us should be considering. 
IMO these are not those triggers.


>
> Of course, you can have books that get their edition 0 updated in book
> while you're upgrading. But the editions feature code always treats
> that old update as an update to edition 0.  It's still the same object
> it always was, your app just makes some assumptions about it. You can
> use a union in some cases where you need to see them all for instance,
> and just select a literal '0' for the edition column of your union.

I find unions to be very awkward and really subject to poor performance. 
  Of course this can be made to work but I'm sticking to my preference 
for getting the data in the right shape on the write side, not the read 
side.

>
> And one can say "old app is gone" when one knows it's gone. At that point,
> one can run a migration that inserts 0 editions into book_edition, and
> drops the book table. For OpenStack, we can say "all releases that used
> that old schema are EOL, so we can simplify the code now". Our 6 month
> pace and short EOL windows are built for this kind of thing.

Assuming we aren't able to use Nova's approach and we're stuck 
translating in the data access layer, we can simplify the code and put 
out a new release, although that "simplified" code now has to be 
"unsimplified" by all the *new* schema changes - code will always be 
carrying along junk to try and adapt it to the previous version of the 
software.   There's no problem if projects in this situation want to do 
it this way and I will gladly support everyone's efforts in going this 
route.    However, I still think it's worth looking into approaches that 
can push the interaction between old and new app version into the write 
side instead of the read side, and if that interaction can be removed 
from the primary database access code into a separate layer.

To the degree that teams can just emulate Nova's finessing of the issue 
at the service level, that's even better.   This thread is just in 
response to particular teams who *want* to use triggers for a specific 
problem.    Hopefully I will have time to flesh out my alternative 
technique for "application-level translation triggers" and maybe those 
folks might want to try that kind of thing too someday.