Sqlalchemy

Latest version: v2.0.31

Safety actively analyzes 640296 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 32 of 50

1.0.1

Not secure
:released: April 23, 2015

.. change::
:tags: bug, firebird
:tickets: 3380

Fixed a regression due to :ticket:`3034` where limit/offset
clauses were not properly interpreted by the Firebird dialect.
Pull request courtesy effem-git.

.. change::
:tags: bug, firebird
:tickets: 3381

Fixed support for "literal_binds" mode when using limit/offset
with Firebird, so that the values are again rendered inline when
this is selected. Related to :ticket:`3034`.

.. change::
:tags: bug, sqlite
:tickets: 3378

Fixed a regression due to :ticket:`3282`, where due to the fact that
we attempt to assume the availability of ALTER when creating/dropping
schemas, in the case of SQLite we simply said to not worry about
foreign keys at all, since ALTER is not available, when creating
and dropping tables. This meant that the sorting of tables was
basically skipped in the case of SQLite, and for the vast majority
of SQLite use cases, this is not an issue.

However, users who were doing DROPs on SQLite
with tables that contained data and with referential integrity
turned on would then experience errors, as the
dependency sorting *does* matter in the case of DROP with
enforced constraints, when those tables have data (SQLite will still
happily let you create foreign keys to nonexistent tables and drop
tables referring to existing ones with constraints enabled, as long as
there's no data being referenced).

In order to maintain the new feature of :ticket:`3282` while still
allowing a SQLite DROP operation to maintain ordering, we now
do the sort with full FKs taken under consideration, and if we encounter
an unresolvable cycle, only *then* do we forego attempting to sort
the tables; we instead emit a warning and go with the unsorted list.
If an environment needs both ordered DROPs *and* has foreign key
cycles, then the warning notes they will need to restore the
``use_alter`` flag to their :class:`_schema.ForeignKey` and
:class:`_schema.ForeignKeyConstraint` objects so that just those objects will
be omitted from the dependency sort.

.. seealso::

:ref:`feature_3282` - contains an updated note about SQLite.

.. change::
:tags: bug, sql
:tickets: 3372

Fixed issue where a straight SELECT EXISTS query would fail to
assign the proper result type of Boolean to the result mapping, and
instead would leak column types from within the query into the
result map. This issue exists in 0.9 and earlier as well, however
has less of an impact in those versions. In 1.0, due to :ticket:`918`
this becomes a regression in that we now rely upon the result mapping
to be very accurate, else we can assign result-type processors to
the wrong column. In all versions, this issue also has the effect
that a simple EXISTS will not apply the Boolean type handler, leading
to simple 1/0 values for backends without native boolean instead of
True/False. The fix includes that an EXISTS columns argument
will be anon-labeled like other column expressions; a similar fix is
implemented for pure-boolean expressions like ``not_(True())``.

.. change::
:tags: bug, orm
:tickets: 3374

Fixed issue where a query of the form
``query(B).filter(B.a != A(id=7))`` would render the ``NEVER_SET``
symbol, when
given a transient object. For a persistent object, it would
always use the persisted database value and not the currently
set value. Assuming autoflush is turned on, this usually would
not be apparent for persistent values, as any pending changes
would be flushed first in any case. However, this is inconsistent
vs. the logic used for the non-negated comparison,
``query(B).filter(B.a == A(id=7))``, which does use the
current value and additionally allows comparisons to transient
objects. The comparison now uses the current value and not
the database-persisted value.

Unlike the other ``NEVER_SET`` issues that are repaired as regressions
caused by :ticket:`3061` in this release, this particular issue is
present at least as far back as 0.8 and possibly earlier, however it
was discovered as a result of repairing the related ``NEVER_SET``
issues.

.. seealso::

:ref:`bug_3374`

.. change::
:tags: bug, orm
:tickets: 3371

Fixed unexpected use regression cause by :ticket:`3061` where
the NEVER_SET
symbol could leak into relationship-oriented queries, including
``filter()`` and ``with_parent()`` queries. The ``None`` symbol
is returned in all cases, however many of these queries have never
been correctly supported in any case, and produce comparisons
to NULL without using the IS operator. For this reason, a warning
is also added to that subset of relationship queries that don't
currently provide for ``IS NULL``.

.. seealso::

:ref:`bug_3371`


.. change::
:tags: bug, orm
:tickets: 3368

Fixed a regression caused by :ticket:`3061` where the
NEVER_SET symbol could leak into a lazyload query, subsequent
to the flush of a pending object. This would occur typically
for a many-to-one relationship that does not use a simple
"get" strategy. The good news is that the fix improves efficiency
vs. 0.9, because we can now skip the SELECT statement entirely
when we detect NEVER_SET symbols present in the parameters; prior to
:ticket:`3061`, we couldn't discern if the None here were set or not.


.. changelog::

1.0.0

Not secure
:released: April 16, 2015

.. change::
:tags: bug, orm
:tickets: 3367

Identified an inconsistency when handling :meth:`_query.Query.join` to the
same target more than once; it implicitly dedupes only in the case of
a relationship join, and due to :ticket:`3233`, in 1.0 a join
to the same table twice behaves differently than 0.9 in that it no
longer erroneously aliases. To help document this change,
the verbiage regarding :ticket:`3233` in the migration notes has
been generalized, and a warning has been added when :meth:`_query.Query.join`
is called against the same target relationship more than once.

.. change::
:tags: bug, orm
:tickets: 3364

Made a small improvement to the heuristics of relationship when
determining remote side with semi-self-referential (e.g. two joined
inh subclasses referring to each other), non-simple join conditions
such that the parententity is taken into account and can reduce the
need for using the ``remote()`` annotation; this can restore some
cases that might have worked without the annotation prior to 0.9.4
via :ticket:`2948`.

.. change::
:tags: bug, mssql
:tickets: 3360

Fixed a regression where the "last inserted id" mechanics would
fail to store the correct value for MSSQL on an INSERT where the
primary key value was present in the insert params before execution,
as well as in the case where an INSERT from SELECT would state the
target columns as column objects, instead of string keys.


.. change::
:tags: bug, mssql

Using the ``Binary`` constructor now present in pymssql rather than
patching one in. Pull request courtesy Ramiro Morales.

.. change::
:tags: bug, tests
:tickets: 3356

Fixed the pathing used when tests run; for sqla_nose.py and py.test,
the "./lib" prefix is again inserted at the head of sys.path but
only if sys.flags.no_user_site isn't set; this makes it act just
like the way Python puts "." in the current path by default.
For tox, we are setting the PYTHONNOUSERSITE flag now.

.. change::
:tags: feature, sql
:tickets: 3084

The topological sorting used to sort :class:`_schema.Table` objects
and available via the :attr:`_schema.MetaData.sorted_tables` collection
will now produce a **deterministic** ordering; that is, the same
ordering each time given a set of tables with particular names
and dependencies. This is to help with comparison of DDL scripts
and other use cases. The tables are sent to the topological sort
sorted by name, and the topological sort itself will process
the incoming data in an ordered fashion. Pull request
courtesy Sebastian Bank.

.. seealso::

:ref:`feature_3084`

.. change::
:tags: feature, orm

Added new argument :paramref:`.Query.update.update_args` which allows
kw arguments such as ``mysql_limit`` to be passed to the underlying
:class:`_expression.Update` construct. Pull request courtesy Amir Sadoughi.

.. changelog::

1.0.0b5

Not secure
:released: April 3, 2015

.. change::
:tags: bug, orm
:tickets: 3349

:class:`_query.Query` doesn't support joins, subselects, or special
FROM clauses when using the :meth:`_query.Query.update` or
:meth:`_query.Query.delete` methods; instead of silently ignoring these
fields if methods like :meth:`_query.Query.join` or
:meth:`_query.Query.select_from` has been called, an error is raised.
In 0.9.10 this only emits a warning.

.. change::
:tags: bug, orm

Added a list() call around a weak dictionary used within the
commit phase of the session, which without it could cause
a "dictionary changed size during iter" error if garbage collection
interacted within the process. Change was introduced by
3139.

.. change::
:tags: bug, postgresql
:tickets: 3343

Fixed bug where updated PG index reflection as a result of
:ticket:`3184` would cause index operations to fail on PostgreSQL
versions 8.4 and earlier. The enhancements are now
disabled when using an older version of PostgreSQL.

.. change::
:tags: bug, sql
:tickets: 3346

The warning emitted by the unicode type for a non-unicode type
has been liberalized to warn for values that aren't even string
values, such as integers; previously, the updated warning system
of 1.0 made use of string formatting operations which
would raise an internal TypeError. While these cases should ideally
raise totally, some backends like SQLite and MySQL do accept them
and are potentially in use by legacy code, not to mention that they
will always pass through if unicode conversion is turned off
for the target backend.

.. change::
:tags: bug, orm
:tickets: 3347

Fixed a bug related to "nested" inner join eager loading, which
exists in 0.9 as well but is more of a regression in 1.0 due to
:ticket:`3008` which turns on "nested" by default, such that
a joined eager load that travels across sibling paths from a common
ancestor using innerjoin=True will correctly splice each "innerjoin"
sibling into the appropriate part of the join, when a series of
inner/outer joins are mixed together.

.. changelog::

1.0.0b4

Not secure
:released: March 29, 2015

.. change::
:tags: bug, mssql, oracle, firebird, sybase
:tickets: 3338

Turned off the "simple order by" flag on the MSSQL, Oracle dialects;
this is the flag that per :ticket:`2992` causes an order by or group by
an expression that's also in the columns clause to be copied by
label, even if referenced as the expression object. The behavior
for MSSQL is now the old behavior that copies the whole expression
in by default, as MSSQL can be picky on these particularly in
GROUP BY expressions. The flag is also turned off defensively
for the Firebird and Sybase dialects.

.. note:: this resolution was incorrect, please see version 1.0.2
for a rework of this resolution.

.. change::
:tags: feature, schema
:tickets: 3341

The "auto-attach" feature of constraints such as :class:`.UniqueConstraint`
and :class:`.CheckConstraint` has been further enhanced such that
when the constraint is associated with non-table-bound :class:`_schema.Column`
objects, the constraint will set up event listeners with the
columns themselves such that the constraint auto attaches at the
same time the columns are associated with the table. This in particular
helps in some edge cases in declarative but is also of general use.

.. seealso::

:ref:`change_3341`

.. change::
:tags: bug, sql
:tickets: 3340

Fixed bug in new "label resolution" feature of :ticket:`2992` where
a label that was anonymous, then labeled again with a name, would
fail to be locatable via a textual label. This situation occurs
naturally when a mapped :func:`.column_property` is given an
explicit label in a query.

.. change::
:tags: bug, sql
:tickets: 3335

Fixed bug in new "label resolution" feature of :ticket:`2992` where
the string label placed in the order_by() or group_by() of a statement
would place higher priority on the name as found
inside the FROM clause instead of a more locally available name
inside the columns clause.

.. changelog::

1.0.0b3

Not secure
:released: March 20, 2015

.. change::
:tags: bug, mysql
:tickets: 2771

Repaired the commit for issue 2771 which was inadvertently commented
out.


.. changelog::

1.0.0b2

Not secure
:released: March 20, 2015

.. change::
:tags: bug, mysql
:tickets: 2771

Fixes to fully support using the ``'utf8mb4'`` MySQL-specific charset
with MySQL dialects, in particular MySQL-Python and PyMySQL. In
addition, MySQL databases that report more unusual charsets such as
'koi8u' or 'eucjpms' will also work correctly. Pull request
courtesy Thomas Grainger.

.. change::
:tags: change, orm, declarative
:tickets: 3331

Loosened some restrictions that were added to ``declared_attr``
objects, such that they were prevented from being called outside
of the declarative process; this is related to the enhancements
of 3150 which allow ``declared_attr`` to return a value that is
cached based on the current class as it's being configured.
The exception raise has been removed, and the behavior changed
so that outside of the declarative process, the function decorated by
``declared_attr`` is called every time just like a regular
``property``, without using any caching, as none is available
at this stage.

.. change::
:tags: bug, engine
:tickets: 3330, 3329

The "auto close" for :class:`_engine.ResultProxy` is now a "soft" close.
That is, after exhausting all rows using the fetch methods, the
DBAPI cursor is released as before and the object may be safely
discarded, but the fetch methods may continue to be called for which
they will return an end-of-result object (None for fetchone, empty list
for fetchmany and fetchall). Only if :meth:`_engine.ResultProxy.close`
is called explicitly will these methods raise the "result is closed"
error.

.. seealso::

:ref:`change_3330`

.. change::
:tags: bug, orm
:tickets: 3327

Fixed unexpected use regression from pullreq github:137 where
Py2K unicode literals (e.g. ``u""``) would not be accepted by the
:paramref:`_orm.relationship.cascade` option.
Pull request courtesy Julien Castets.


.. changelog::

Page 32 of 50

Links

Releases

Has known vulnerabilities

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.