Open Stack

Mike,

On Tue, Jul 19, 2016 at 7:40 AM, Mike Bayer <mbayer at 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