From 98c18ae8645db9ddda5cb6ca0176e916d65310ca Mon Sep 17 00:00:00 2001 From: Mike Bayer Date: Thu, 12 Oct 2017 11:15:11 -0400 Subject: [PATCH] - make a note in 1.1 migration notes for ref #4102 Change-Id: If9edba3af476bc4303246e55d0ecb53009084342 (cherry picked from commit 9ffee8c94a2ed586b2d1abe404276a044078b8ca) --- doc/build/changelog/migration_11.rst | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/doc/build/changelog/migration_11.rst b/doc/build/changelog/migration_11.rst index c790e46411..aa751a6c3e 100644 --- a/doc/build/changelog/migration_11.rst +++ b/doc/build/changelog/migration_11.rst @@ -1646,6 +1646,21 @@ with the pure-Python int-to-boolean processor and is more forgiving of existing data already within the database. Values of None/NULL are as before retained as None/NULL. +.. note:: + + this change had an unintended side effect that the interpretation of non- + integer values, such as strings, also changed in behavior such that the + string value ``"0"`` would be interpreted as "true", but only on backends + that don't have a native boolean datatype - on "native boolean" backends + like Postgresql, the string value ``"0"`` is passed directly to the driver + and is interpreted as "false". This is an inconsistency that did not occur + with the previous implementation.It should be noted that passing strings or + any other value outside of ``None``, ``True``, ``False``, ``1``, ``0`` to + the :class:`.Boolean` datatype is **not supported** and version 1.2 will + raise an error for this scenario (or possibly just emit a warning, TBD). + See also :ticket:`4102`. + + :ticket:`3730` .. _change_2837: -- 2.47.2