<div dir="ltr"><div>Thanks for the follow up, maybe we need document the issue and work around in some place, in alembic?<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-07-24 23:21 GMT+08:00 Michael Bayer <span dir="ltr"><<a href="mailto:mbayer@redhat.com" target="_blank">mbayer@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">hey good news, the owner of the issue upstream found that the SQL<br>
standard agrees with my proposed behavior.   So while this is current<br>
MariaDB 10.2 / 10.3 behavior, hopefully it will be resolved in an<br>
upcoming release within those series.   not sure of the timing though<br>
so we may not be able to duck it.<br>
<div class="HOEnZb"><div class="h5"><br>
On Mon, Jul 24, 2017 at 11:16 AM, Michael Bayer <<a href="mailto:mbayer@redhat.com">mbayer@redhat.com</a>> wrote:<br>
> On Mon, Jul 24, 2017 at 10:37 AM, Doug Hellmann <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>> wrote:<br>
>> Excerpts from Michael Bayer's message of 2017-07-23 16:39:20 -0400:<br>
>>> Hey list -<br>
>>><br>
>>> It appears that MariaDB as of version 10.2 has made an enhancement<br>
>>> that overall is great and fairly historic in the MySQL community,<br>
>>> they've made CHECK constraints finally work.   For all of MySQL's<br>
>>> existence, you could emit a CREATE TABLE statement that included CHECK<br>
>>> constraint, but the CHECK phrase would be silently ignored; there are<br>
>>> no actual CHECK constraints in MySQL.<br>
>>><br>
>>> Mariadb 10.2 has now made CHECK do something!  However!  the bad news!<br>
>>>  They have decided that the CHECK constraint against a single column<br>
>>> should not be implicitly dropped if you drop the column [1].   In case<br>
>>> you were under the impression your SQLAlchemy / oslo.db project<br>
>>> doesn't use CHECK constraints, if you are using the SQLAlchemy Boolean<br>
>>> type, or the "ENUM" type without using MySQL's native ENUM feature<br>
>>> (less likely), there's a simple CHECK constraint in there.<br>
>>><br>
>>> So far the Zun project has reported the first bug on Alembic [2] that<br>
>>> they can't emit a DROP COLUMN for a boolean column.    In [1] I've<br>
>>> made my complete argument for why this decision on the MariaDB side is<br>
>>> misguided.   However, be on the lookout for boolean columns that can't<br>
>>> be DROPPED on some environments using newer MariaDB.  Workarounds for<br>
>>> now include:<br>
>>><br>
>>> 1. when using Boolean(), set create_constraint=False<br>
>>><br>
>>> 2. when using Boolean(), make sure it has a "name" to give the<br>
>>> constraint, so that later you can DROP CONSTRAINT easily<br>
>>><br>
>>> 3. if not doing #1 and #2, in order to drop the column you need to use<br>
>>> the inspector (e.g. from sqlalchemy import inspect; inspector =<br>
>>> inspect(engine)) and locate all the CHECK constraints involving the<br>
>>> target column, and then drop them by name.<br>
>><br>
>> Item 3 sounds like the description of a helper function we could add to<br>
>> oslo.db for use in migration scripts.<br>
><br>
> OK let me give a little bit more context, that if MariaDB holds steady<br>
> here, I will have to implement #3 within Alembic itself (though yes,<br>
> for SQLAlchemy-migrate, still needed :) ).     MS SQL Server has the<br>
> same limitation for CHECK constraints and Alembic provides for a<br>
> SQL-only procedure that can run as a static SQL element on that<br>
> backend; hopefully the same is possible for MySQL.<br>
><br>
><br>
><br>
>><br>
>> Doug<br>
>><br>
>>><br>
>>> [1] <a href="https://jira.mariadb.org/browse/MDEV-11114" rel="noreferrer" target="_blank">https://jira.mariadb.org/<wbr>browse/MDEV-11114</a><br>
>>><br>
>>> [2] <a href="https://bitbucket.org/zzzeek/alembic/issues/440/cannot-drop-boolean-column-in-mysql" rel="noreferrer" target="_blank">https://bitbucket.org/zzzeek/<wbr>alembic/issues/440/cannot-<wbr>drop-boolean-column-in-mysql</a><br>
>>><br>
>><br>
>> ______________________________<wbr>______________________________<wbr>______________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>ChangBo Guo(gcb)</div></div></div>
</div>