Open Stack

Hi Steven,

Nice catch! This is not the first time MySQL has played a joke on us...

I think, we can fix this easily by adding a callback function, which will
set the proper sql_mode value, when a DB connection is retrieved from a
connection pool.

We'll provide a fix to oslo-incubator soon.

Thanks,
Roman

[1] http://www.enricozini.org/2012/tips/sa-sqlmode-traditional/


On Wed, Sep 11, 2013 at 1:37 PM, Steven Hardy <shardy at redhat.com> wrote:

> Hi all,
>
> I'm investigating some issues, where data stored to a text column in mysql
> is silently truncated if it's too big.
>
> It appears that the default configuration of mysql, and the sessions
> established via sqlalchemy is to simply warn on truncation rather than
> raise an error.
>
> This seems to me to be almost never what you want, since on retrieval the
> data is corrupt and bad/unexpected stuff is likely.
>
> This AFAICT is a mysql specific issue[1], which can be resolved by setting
> sql_mode to "traditional"[2,3], after which an error is raised on
> truncation,
> allowing us to catch the error before the data is stored.
>
> My question is, how do other projects, or oslo.db, handle this atm?
>
> It seems we either have to make sure the DB enforces the schema/model, or
> validate every single value before attempting to store, which seems like an
> unreasonable burden given that the schema changes pretty regularly.
>
> Can any mysql, sqlalchemy and oslo.db experts pitch in with opinions on
> this?
>
> Thanks!
>
> Steve
>
> [1] http://www.enricozini.org/2012/tips/sa-sqlmode-traditional/
> [2]
> http://rpbouman.blogspot.co.uk/2009/01/mysqls-sqlmode-my-suggestions.html
> [3] http://dev.mysql.com/doc/refman/5.5/en/server-sql-mode.html
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130911/9f15bf42/attachment.html>