github sqlalchemy/sqlalchemy rel_1_3_11
1.3.11

latest releases: rel_2_0_29, rel_2_0_28, rel_1_4_52...
4 years ago

1.3.11

Released: November 11, 2019

orm

  • [orm] [usecase] Added accessor Query.is_single_entity() to Query, which
    will indicate if the results returned by this Query will be a
    list of ORM entities, or a tuple of entities or column expressions.
    SQLAlchemy hopes to improve upon the behavior of single entity / tuples in
    future releases such that the behavior would be explicit up front, however
    this attribute should be helpful with the current behavior. Pull request
    courtesy Patrick Hayes.

    References: #4934

  • [orm] [bug] The relationship.omit_join flag was not intended to be
    manually set to True, and will now emit a warning when this occurs. The
    omit_join optimization is detected automatically, and the omit_join
    flag was only intended to disable the optimization in the hypothetical case
    that the optimization may have interfered with correct results, which has
    not been observed with the modern version of this feature. Setting the
    flag to True when it is not automatically detected may cause the selectin
    load feature to not work correctly when a non-default primary join
    condition is in use.

    References: #4954

  • [orm] [bug] A warning is emitted if a primary key value is passed to Query.get()
    that consists of None for all primary key column positions. Previously,
    passing a single None outside of a tuple would raise a TypeError and
    passing a composite None (tuple of None values) would silently pass
    through. The fix now coerces the single None into a tuple where it is
    handled consistently with the other None conditions. Thanks to Lev
    Izraelit for the help with this.

    References: #4915

  • [orm] [bug] The BakedQuery will not cache a query that was modified by a
    QueryEvents.before_compile() event, so that compilation hooks that
    may be applying ad-hoc modifications to queries will take effect on each
    run. In particular this is helpful for events that modify queries used in
    lazy loading as well as eager loading such as "select in" loading. In
    order to re-enable caching for a query modified by this event, a new
    flag bake_ok is added; see baked_with_before_compile for
    details.

    A longer term plan to provide a new form of SQL caching should solve this
    kind of issue more comprehensively.

    References: #4947

  • [orm] [bug] Fixed ORM bug where a "secondary" table that referred to a selectable which
    in some way would refer to the local primary table would apply aliasing to
    both sides of the join condition when a relationship-related join, either
    via Query.join() or by joinedload(), were generated. The
    "local" side is now excluded.

    References: #4974

engine

  • [engine] [bug] Fixed bug where parameter repr as used in logging and error reporting needs
    additional context in order to distinguish between a list of parameters for
    a single statement and a list of parameter lists, as the "list of lists"
    structure could also indicate a single parameter list where the first
    parameter itself is a list, such as for an array parameter. The
    engine/connection now passes in an additional boolean indicating how the
    parameters should be considered. The only SQLAlchemy backend that expects
    arrays as parameters is that of psycopg2 which uses pyformat parameters,
    so this issue has not been too apparent, however as other drivers that use
    positional gain more features it is important that this be supported. It
    also eliminates the need for the parameter repr function to guess based on
    the parameter structure passed.

    References: #4902

  • [engine] [bug] [postgresql] Fixed bug in Inspector where the cache key generation did not
    take into account arguments passed in the form of tuples, such as the tuple
    of view name styles to return for the PostgreSQL dialect. This would lead
    the inspector to cache too generally for a more specific set of criteria.
    The logic has been adjusted to include every keyword element in the cache,
    as every argument is expected to be appropriate for a cache else the
    caching decorator should be bypassed by the dialect.

    References: #4955

sql

  • [sql] [bug] [py3k] Changed the repr() of the quoted_name construct to use
    regular string repr() under Python 3, rather than running it through
    "backslashreplace" escaping, which can be misleading.

    References: #4931

  • [sql] [usecase] Added new accessors to expressions of type JSON to allow for
    specific datatype access and comparison, covering strings, integers,
    numeric, boolean elements. This revises the documented approach of
    CASTing to string when comparing values, instead adding specific
    functionality into the PostgreSQL, SQlite, MySQL dialects to reliably
    deliver these basic types in all cases.

    References: #4276

  • [sql] [usecase] The text() construct now supports "unique" bound parameters, which
    will dynamically uniquify themselves on compilation thus allowing multiple
    text() constructs with the same bound parameter names to be combined
    together.

    References: #4933

schema

  • [schema] [bug] Fixed bug where a table that would have a column label overlap with a plain
    column name, such as "foo.id AS foo_id" vs. "foo.foo_id", would prematurely
    generate the ._label attribute for a column before this overlap could
    be detected due to the use of the index=True or unique=True flag on
    the column in conjunction with the default naming convention of
    "column_0_label". This would then lead to failures when ._label
    were used later to generate a bound parameter name, in particular those
    used by the ORM when generating the WHERE clause for an UPDATE statement.
    The issue has been fixed by using an alternate ._label accessor for DDL
    generation that does not affect the state of the Column. The
    accessor also bypasses the key-deduplication step as it is not necessary
    for DDL, the naming is now consistently "<tablename>_<columnname>"
    without any subsequent numeric symbols when used in DDL.

    References: #4911

  • [schema] [usecase] Added DDL support for "computed columns"; these are DDL column
    specifications for columns that have a server-computed value, either upon
    SELECT (known as "virtual") or at the point of which they are INSERTed or
    UPDATEd (known as "stored"). Support is established for Postgresql, MySQL,
    Oracle SQL Server and Firebird. Thanks to Federico Caselli for lots of work
    on this one.

    References: #4894

mysql

  • [mysql] [bug] Added "Connection was killed" message interpreted from the base
    pymysql.Error class in order to detect closed connection, based on reports
    that this message is arriving via a pymysql.InternalError() object which
    indicates pymysql is not handling it correctly.

    References: #4945

mssql

  • [mssql] [bug] Fixed issue in MSSQL dialect where an expression-based OFFSET value in a
    SELECT would be rejected, even though the dialect can render this
    expression inside of a ROW NUMBER-oriented LIMIT/OFFSET construct.

    References: #4973

  • [mssql] [bug] Fixed an issue in the Engine.table_names() method where it would
    feed the dialect's default schema name back into the dialect level table
    function, which in the case of SQL Server would interpret it as a
    dot-tokenized schema name as viewed by the mssql dialect, which would
    cause the method to fail in the case where the database username actually
    had a dot inside of it. In 1.3, this method is still used by the
    MetaData.reflect() function so is a prominent codepath. In 1.4,
    which is the current master development branch, this issue doesn't exist,
    both because MetaData.reflect() isn't using this method nor does the
    method pass the default schema name explicitly. The fix nonetheless
    guards against the default server name value returned by the dialect from
    being interpreted as dot-tokenized name under any circumstances by
    wrapping it in quoted_name().

    References: #4923

oracle

  • [oracle] [bug] [firebird] Modified the approach of "name normalization" for the Oracle and Firebird
    dialects, which converts from the UPPERCASE-as-case-insensitive convention
    of these dialects into lowercase-as-case-insensitive for SQLAlchemy, to not
    automatically apply the quoted_name construct to a name that
    matches itself under upper or lower case conversion, as is the case for
    many non-european characters. All names used within metadata structures
    are converted to quoted_name objects in any case; the change
    here would only affect the output of some inspection functions.

    References: #4931

  • [oracle] [usecase] Added dialect-level flag encoding_errors to the cx_Oracle dialect,
    which can be specified as part of create_engine(). This is passed
    to SQLAlchemy's unicode decoding converter under Python 2, and to
    cx_Oracle's cursor.var() object as the encodingErrors parameter
    under Python 3, for the very unusual case that broken encodings are present
    in the target database which cannot be fetched unless error handling is
    relaxed. The value is ultimately one of the Python "encoding errors"
    parameters passed to decode().

    References: #4799

  • [oracle] [bug] The sqltypes.NCHAR datatype will now bind to the
    cx_Oracle.FIXED_NCHAR DBAPI data bindings when used in a bound
    parameter, which supplies proper comparison behavior against a
    variable-length string. Previously, the sqltypes.NCHAR datatype
    would bind to cx_oracle.NCHAR which is not fixed length; the
    sqltypes.CHAR datatype already binds to cx_Oracle.FIXED_CHAR
    so it is now consistent that sqltypes.NCHAR binds to
    cx_Oracle.FIXED_NCHAR.

    References: #4913

firebird

  • [firebird] [bug] Added additional "disconnect" message "Error writing data to the
    connection" to Firebird disconnection detection. Pull request courtesy
    lukens.

    References: #4903

misc

  • [bug] [tests] Fixed test failures which would occur with newer SQLite as of version 3.30
    or greater, due to their addition of nulls ordering syntax as well as new
    restrictions on aggregate functions. Pull request courtesy Nils Philippsen.

    References: #4920

  • [bug] [installation] [windows] Added a workaround for a setuptools-related failure that has been observed
    as occurring on Windows installations, where setuptools is not correctly
    reporting a build error when the MSVC build dependencies are not installed
    and therefore not allowing graceful degradation into non C extensions
    builds.

    References: #4967

Don't miss a new sqlalchemy release

NewReleases is sending notifications on new releases.