Mike, On Tue, Jul 19, 2016 at 7:40 AM, Mike Bayer <mba...@redhat.com> wrote: > Note that I use the term "function" and not "procedure" to stress that this > is not a "stored procedure" in the traditional sense of performing complex > business logic and persistence operations - this CIDR function performs a > calculation that is not at all specific to Openstack, and is provided > already by other databases as a built-in, and nothing else.
My only concern would be that based on my previous experience these things easily get complicated and large pieces of hard to maintain logic. We need to be careful here and consider new additions on case by case basis. > The general verbosity and unfamiliarity of these well known SQL features is > understandably being met with trepidation. I've identified that this > trepidation is likely rooted in the fact that unlike the many other > elaborate SQL features we use like ALTER TABLE, savepoints, subqueries, > SELECT FOR UPDATE, isolation levels, etc. etc., there is no warm and fuzzy > abstraction layer here that is both greatly reducing the amount of explicit > code needed to produce and upgrade the feature, as well as indicating that > "someone else" will fix this system when it has problems. > > Rather than hobbling the entire Openstack ecosystem to using a small subset > of what our relational databases are capable of, I'd like to propose that > preferably somewhere in oslo.db, or elsewhere, we begin providing the > foundation for the use of SQL features that are rooted in mechanisms such as > triggers and small use of stored functions, and more specifically begin to > produce network-math SQL features as the public API, starting with this one. If people are already using that, we might as well put this into oslo.db and make their lives easier a bit. It would be really nice to have fallback to Python implementations of such functions whenever possible, though. This will likely make it harder to change a DB backend for a particular project in the future, if it uses this advanced API, but IMO it's really up to consuming projects to decide which DB backends they support and test. They just should be aware of what they are doing and weigh all the pros and cons first. Thanks, Roman __________________________________________________________________________ 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
