Ensured that the queries used to reflect indexes and view definitions will
explicitly CAST string parameters into NVARCHAR, as many SQL Server drivers
frequently treat string values, particularly those with non-ascii
characters or larger string values, as TEXT which often don't compare
correctly against VARCHAR characters in SQL Server's information schema
tables for some reason. These CAST operations already take place for
reflection queries against SQL Server ``information_schema.`` tables but
were missing from three additional queries that are against ``sys.``
tables.
Fixes: #4745
Change-Id: I3056533bf1a1e8ef17742879d369ab13f8b704ea
Unfortunately target version py27 makes Black want to break
print functions, even if you put a "from __future__ import print_function"
at the top, so it is being inconsistent in its "we've decided this
is a python 2 file" logic and basically this thing really needs
command line arguments
Change-Id: Iefa62df4224b9620e764b16b1c390647f948e85f
Fixed bug where the special logic to render "NULL" for the
:class:`.TIMESTAMP` datatype when ``nullable=True`` would not work if the
column's datatype were a :class:`.TypeDecorator` or a :class:`.Variant`.
The logic now ensures that it unwraps down to the original
:class:`.TIMESTAMP` so that this special case NULL keyword is correctly
rendered when requested.
Fixes: #4743
Change-Id: I02b22dfa3db06daea37b044e2206a8569e2e5d22
These tests in of_type were relying upon generating the
polymorphic selectable from the mapper which is proving to be
more challenging to correct when that mechanism is changing.
Change-Id: I72635fab0f6f3fc7f2b712596db310648f55b04c
The "NO ACTION" keyword for foreign key "ON UPDATE" is now considered to be
the default cascade for a foreign key on all supporting backends (SQlite,
MySQL, PostgreSQL) and when detected is not included in the reflection
dictionary; this is already the behavior for PostgreSQL and MySQL for all
previous SQLAlchemy versions in any case. The "RESTRICT" keyword is
positively stored when detected; PostgreSQL does report on this keyword,
and MySQL as of version 8.0 does as well. On earlier MySQL versions, it is
not reported by the database.
Fixes: #4741
Change-Id: I6becf1f2450605c1991158bb8a04d954dcc7396c
Since our various eq_(), ne_() etc. functions use assert, pytest
can rewrite this module using its enhanced string reporting.
very helpful for comparing SQL strings
Change-Id: Ia71328401fd7965bcb14eb1ccea0dc48a8f2c3ea
The memusage tests are extremely time and memory intensive,
and when CI runs against MySQL or Postgresql there are many
database/driver combinations for which the "backend" tests
repeatedly run; as these tests are more oriented towards
basic dialect interaction, add a new "sparse" backend option
that will run the tests only once per base dialect.
Change-Id: I312aa0332d7ec1ff4e2faa15f6b189d6f0f68393
This is a very useful assertion which prevents unused variables
from being set up allows code to be more readable and sometimes
even more efficient. test suites seem to be where the most
problems are and there do not seem to be documentation examples
that are using this, or at least the linter is not taking effect
within rst blocks.
Change-Id: I2b3341d8dd14da34879d8425838e66a4b9f8e27d
This compat name is not used and is also referring to a
deprecated API for the win32 case.
Fixes: #4731
Change-Id: I0f2b07347c15455b58c27e29a19fb55e159f332a
Added support for column sorting flags when reflecting indexes for
PostgreSQL, including ASC, DESC, NULLSFIRST, NULLSLAST. Also adds this
facility to the reflection system in general which can be applied to other
dialects in future releases. Pull request courtesy Eli Collins.
Fixes: #4717Closes: #4725
Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/4725
Pull-request-sha: 3cbb067bd4
Change-Id: I8b0617d68580cfe4ff79d758a077263f33e852c2
Fixed a series of quoting issues which all stemmed from the concept of the
:func:`.literal_column` construct, which when being "proxied" through a
subquery to be referred towards by a label that matches its text, the label
would not have quoting rules applied to it, even if the string in the
:class:`.Label` were set up as a :class:`.quoted_name` construct. Not
applying quoting to the text of the :class:`.Label` is a bug because this
text is strictly a SQL identifier name and not a SQL expression, and the
string should not have quotes embedded into it already unlike the
:func:`.literal_column` which it may be applied towards. The existing
behavior of a non-labeled :func:`.literal_column` being propagated as is on
the outside of a subquery is maintained in order to help with manual
quoting schemes, although it's not clear if valid SQL can be generated for
such a construct in any case.
Fixes: #4730
Change-Id: I300941f27872fc4298c74a1d1ed65aef1a5cdd82
Fixed bug where the :attr:`.Mapper.all_orm_descriptors` accessor would
return an entry for the :class:`.Mapper` itself under the declarative
``__mapper___`` key, when this is not a descriptor. The ``.is_attribute``
flag that's present on all :class:`.InspectionAttr` objects is now
consulted, which has also been modified to be ``True`` for an association
proxy, as it was erroneously set to False for this object.
Fixes: #4729
Change-Id: Ia02388cc25d004e32d337140b62a587f3e5a0b7b
The LIMIT / OFFSET scheme used in Oracle now makes use of named subqueries
rather than unnamed subqueries when it transparently rewrites a SELECT
statement to one that uses a subquery that includes ROWNUM. The change is
part of a larger change where unnamed subqueries are no longer directly
supported by Core, as well as to modernize the internal use of the select()
construct within the Oracle dialect.
Change-Id: I27605d7cf16ce79f9d577dbc84e3bd51b7c9b4ae
The Alias object no longer has "element" and "original", it now
has "wrapped" and "element" (the name .original is also left
as a descriptor for legacy access by third party dialects).
These two data members refer to the
dual roles Alias needs to play, where in the Python sense it needs
to refer to the thing it was applied against directly, whereas in the
SQL sense it needs to refer to the ultimate "non-alias" thing it
refers towards. Both are necessary to maintain. However, the change
here has each Alias object access the non-Alias object immediately
so that the "unwrapping" is simpler and does not need any special
logic.
In the SQL sense, Alias objects don't nest, the only potential
was that of the CTE, however there is no such thing as
a nested CTE, see link below.
This change is an interim change along the way to breaking Alias
into more classes and breaking away Select objects from being
FromClause objects.
Change-Id: Ie7a0d064226cb074ca745505129b5ec7d879e389
References: https://stackoverflow.com/questions/1413516/can-you-create-nested-with-clauses-for-common-table-expressions
Also fix DetectKeySwitch for intermediary class relationship
Fixed a series of related bugs regarding joined table inheritance more than
two levels deep, in conjunction with modification to primary key values,
where those primary key columns are also linked together in a foreign key
relationship as is typical for joined table inheritance. The intermediary
table in a three-level inheritance hierachy will now get its UPDATE if
only the primary key value has changed and passive_updates=False (e.g.
foreign key constraints not being enforced), whereas before it would be
skipped; similarly, with passive_updates=True (e.g. ON UPDATE CASCADE in
effect), the third-level table will not receive an UPDATE statement as was
the case earlier which would fail since CASCADE already modified it. In a
related issue, a relationship linked to a three-level inheritance hierarchy
on the primary key of an intermediary table of a joined-inheritance
hierarchy will also correctly have its foreign key column updated when the
parent object's primary key is modified, even if that parent object is a
subclass of the linked parent class, whereas before these classes would
not be counted.
Fixes: #4723
Change-Id: Idc408ead67702068e64d583a15149dd4beeefc24
Fixed bug where MySQL ON DUPLICATE KEY UPDATE would not accommodate setting
a column to the value NULL. Pull request courtesy Lukáš Banič.
Fixes: #4715Closes: #4716
Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/4716
Pull-request-sha: bfad6e6bdf
Change-Id: Ia8831cc171d131bf3824be8db4fd1d231231bba3
The :class:`.Connection` object will now not clear a rolled-back
transaction until the outermost transaction is explicitly rolled back.
This is essentially the same behavior that the ORM :class:`.Session` has
had for a long time, where an explicit call to ``.rollback()`` on all
enclosing transactions is required for the transaction to logically clear,
even though the DBAPI-level transaction has already been rolled back.
The new behavior helps with situations such as the "ORM rollback test suite"
pattern where the test suite rolls the transaction back within the ORM
scope, but the test harness which seeks to control the scope of the
transaction externally does not expect a new transaction to start
implicitly.
Fixes: #4712
Change-Id: Ibc6c8d981cff31594a5d26dd5203fd9cfcea1c74
- don't call relatively expensive isEnabledFor(), just call _log_notices
- don't reset the list if it's empty
- fix the test to use a custom function to definitely create a notice, confirmed
that PG seems to no longer create the "implicit sequence" notices
- assert that the reset of the notices works too
- update the docs to illustrate for folks who haven't worked with logging before
Change-Id: I7291e647c177d338e0ad673f3106b4d503e4b3ea
Even though getfullargspec() is no longer deprecated in python3.8
as of b1, we aren't using it anymore so block any future warnings
from interfering with py.test or similar.
Change-Id: Ib96838ce8169e989e1c8ad3a4819b4ebd3ffdc39
In preparation for #4712, add an errors.rst code to the Session's
exception about waiting to be rolled back and rework the FAQ entry
to be much more succinct. When this FAQ was first written, I found
it hard to describe why flush worked this way but as the use case is
clearer now, and #4712 actually showed it being confusing when it doesn't
work this way, we can make a simpler and more definitive statement
about this behavior. Additionally, language about "subtransactions"
is minimized as I might be removing or de-emphasizing this concept in
2.0 (though maybe not as it does seem to work well).
Change-Id: I557872aff255b07e14dd843aa024e027a017afb8
"usecase" indicates the library now supports something a user
was trying to do. It's not quite a "feature" since it's something
that seems like it should have worked, it's not a "bug" because
no mistake was made, it's just something that wasn't considered before.
The advantage of "usecase" is that it inherently suggests a different
style of prioritization vs. something that is preventing the library
from working as designed.
This change also adds docs/build/conf.py under the pep8 formatting
test coverage.
Change-Id: I790ccb799864fec48e4695aedeed2814ab9d493e
Fixed regression in :meth:`.Query.join` where the ``aliased=True`` flag
would not properly apply clause adaptation to filter criteria, if a
previous join were made to the same entity. This is because the adapters
were placed in the wrong order. The order has been reversed so that the
adapter for the most recent ``aliased=True`` call takes precedence as was
the case in 1.2 and earlier. This broke the "elementtree" examples among
other things.
Fixes: #4704
Change-Id: I69f76c97b11157100854d552b5a0ce0103642ec4
Fixed bug where PostgreSQL dialect could not correctly reflect an ENUM
datatype that has no members, returning a list with ``None`` for the
``get_enums()`` call and raising a TypeError when reflecting a column which
has such a datatype. The inspection now returns an empty list.
Fixes: #4701
Change-Id: I202bab19728862cbc64deae211d5ba6a103b8317
Replaced the Python compatbility routines for ``getfullargspec()`` with a
fully vendored version from Python 3.3. Originally, Python was emitting
deprecation warnings for this function in Python 3.8 alphas. While this
change was reverted, it was observed that Python 3 implementations for
``getfullargspec()`` are an order of magnitude slower as of the 3.4 series
where it was rewritten against ``Signature``. While Python plans to
improve upon this situation, SQLAlchemy projects for now are using a simple
replacement to avoid any future issues.
Fixes: #4674
Change-Id: I1ab8729c4072634db80c79bb7bc44197dc5e7114
Reworked the attribute mechanics used by :class:`.AliasedClass` to no
longer rely upon calling ``__getattribute__`` on the MRO of the wrapped
class, and to instead resolve the attribute normally on the wrapped class
using getattr(), and then unwrap/adapt that. This allows a greater range
of attribute styles on the mapped class including special ``__getattr__()``
schemes; but it also makes the code simpler and more resilient in general.
Fixes: #4694
Co-authored-by: Mike Bayer <mike_mp@zzzcomputing.com>
Change-Id: I28901e2472d3c21e881fe5cafa3b1d3af704fad8
While we have the OSI classifier for "MIT License", it looks
like for the "license" field, this is normally just the word
"MIT" and not "MIT License". While the pypa docs suggest we
only need it as the OSI classifier, keep it also in "license"
in order to appease common tooling.
Change-Id: Ife51bbc74d6c1b8ab9a736024818fbba35316e17
Mike Bayer