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.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
