Simplified module pre-loading strategy and made it linter friendly
Introduced a modules registry to register modules that should be lazily loaded
in the package init. This ensures that they are in the system module cache,
avoiding potential thread safety issues as when importing them directly
in the function that uses them. The module registry is used to obtain
these modules directly, ensuring that the all the lazily loaded modules
are resolved at the proper time
This replaces dependency_for decorator and the dependencies decorator logic,
removing the need to pass the resolved modules as arguments of the
decodated functions and removes possible errors caused by linters.
Mike Bayer [Sun, 23 Feb 2020 18:37:18 +0000 (13:37 -0500)]
Decouple compiler state from DML objects; make cacheable
Targeting select / insert / update / delete, the goal
is to minimize overhead of construction and generative methods
so that only the raw arguments passed are handled. An interim
stage that converts the raw state into more compiler-ready state
is added, which is analogous to the ORM QueryContext which will
also be rolled in to be a similar concept, as is currently
being prototyped in I19e05b3424b07114cce6c439b05198ac47f7ac10.
the ORM update/delete BulkUD concept is also going to be rolled
onto this idea. So while the compiler-ready state object,
here called DMLState, looks a little thin, it's the
base of a bigger pattern that will allow for ORM functionality
to embed itself directly into the compiler, execution
context, and result set objects.
This change targets the DML objects, primarily focused on the
values() method which is the most complex process. The
work done by values() is minimized as much as possible
while still being able to create a cache key. Additional
computation is then offloaded to a new object ValuesState
that is handled by the compiler.
Architecturally, a big change here is that insert.values()
and update.values() will generate BindParameter objects for
the values now, which are then carefully received by crud.py
so that they generate the expected names. This is so that
the values() portion of these constructs is cacheable.
for the "multi-values" version of Insert, this is all skipped
and the plan right now is that a multi-values insert is
not worth caching (can always be revisited).
Using the
coercions system in values() also gets us nicer validation
for free, we can remove the NotAClauseElement thing from
schema, and we also now require scalar_subquery() is called
for an insert/update that uses a SELECT as a column value,
1.x deprecation path is added.
The traversal system is then applied to the DML objects
including tests so that they have traversal, cloning, and
cache key support. cloning is not a use case for DML however
having it present allows better validation of the structure
within the tests.
Special per-dialect DML is explicitly not cacheable at the moment,
more as a proof of concept that third party DML constructs can
exist as gracefully not-cacheable rather than producing an
incomplete cache key.
A few selected performance improvements have been added as well,
simplifying the immutabledict.union() method and adding
a new SQLCompiler function that can generate delimeter-separated
clauses like WHERE and ORDER BY without having to build
a ClauseList object at all. The use of ClauseList will
be removed from Select in an upcoming commit. Overall,
ClaustList is unnecessary for internal use and only adds
overhead to statement construction and will likely be removed
as much as possible except for explcit use of conjunctions like
and_() and or_().
Mike Bayer [Wed, 4 Mar 2020 22:44:40 +0000 (17:44 -0500)]
Render VALUES within composed MySQL on duplicate key expressions
Fixed issue in MySQL :meth:`.mysql.Insert.on_duplicate_key_update` construct
where using a SQL function or other composed expression for a column argument
would not properly render the ``VALUES`` keyword surrounding the column
itself.
Mike Bayer [Wed, 4 Mar 2020 00:15:55 +0000 (19:15 -0500)]
Run handle_error for any exceptions raised in execute_context()
Observing a SQLite connection/cursor being hung on
test_resultset -> PositionalTextTest -> test_dupe_col_obj.
this uses connectionless execution and the result object
fails to be constructed. When that happens, there is no path
for the cursor or connection to be closed / released.
Recent changes with the exception assertions in #4849 seem to
be causing a cycle to last a little longer than usual which
is exposing this issue for one particular test on SQLite.
As we want to get rid of weakref cleanup, evaluate
why we dont have handle_dbapi_exception for this whole
block, as after_cursor_execute can raise, result construction
can raise, autocommit can raise, close can raise, there
does not seem to be a reason these things should be outside
of the block that gets cleaned up.
Mike Bayer [Tue, 3 Mar 2020 22:22:30 +0000 (17:22 -0500)]
Restore crud flags if visiting_cte is set
Fixed bug where a CTE of an INSERT/UPDATE/DELETE that also uses RETURNING
could then not be SELECTed from directly, as the internal state of the
compiler would try to treat the outer SELECT as a DELETE statement itself
and access nonexistent state.
Remove the deprecated loader options ``joinedload_all``, ``subqueryload_all``,
``lazyload_all``, ``selectinload_all``. The normal version with method chaining
should be used in their place.
Mike Bayer [Tue, 3 Mar 2020 21:03:39 +0000 (16:03 -0500)]
Don't import provision.py unconditionally
Removed the imports for provision.py from each dialect
and instead added a call in the central provision.py to
a new dialect level method load_provisioning(). The
provisioning registry works in the same way, so an existing
dialect that is using the provision.py system right now
by importing it as part of the package will still continue to
function. However, to avoid pulling in the testing package when
the dialect is used in a non-testing context, the new hook may be
used. Also removed a module-level dependency
of the testing framework on the orm package.
Revised an internal change to the test system added as a result of
:ticket:`5085` where a testing-related module per dialect would be loaded
unconditionally upon making use of that dialect, pulling in SQLAlchemy's
testing framework as well as the ORM into the module import space. This
would only impact initial startup time and memory to a modest extent,
however it's best that these additional modules aren't reverse-dependent on
straight Core usage.
Mike Bayer [Sat, 29 Feb 2020 19:40:45 +0000 (14:40 -0500)]
Ensure all nested exception throws have a cause
Applied an explicit "cause" to most if not all internally raised exceptions
that are raised from within an internal exception catch, to avoid
misleading stacktraces that suggest an error within the handling of an
exception. While it would be preferable to suppress the internally caught
exception in the way that the ``__suppress_context__`` attribute would,
there does not as yet seem to be a way to do this without suppressing an
enclosing user constructed context, so for now it exposes the internally
caught exception as the cause so that full information about the context
of the error is maintained.
Mike Bayer [Mon, 2 Mar 2020 15:28:32 +0000 (10:28 -0500)]
Update dialect API documentation
The docstrings for connect() and on_connect() were incorrect
between Dialect vs. DefaultDialect. Redocumented related
methods, clean up formatting, and remove unicode-related
attribute descriptions from the top level Dialect document
as these don't apply to Python 3.
Mike Bayer [Fri, 28 Feb 2020 19:56:25 +0000 (14:56 -0500)]
Discontinue dynamic __visit_name__
Removed very antiquated logic that checks if __visit_name__
is a property. There's no need for this as the compiler can handle
switching between implementations. Convert _compile_dispatch()
to be fully inlined.
Eric Borczuk [Fri, 28 Feb 2020 16:05:13 +0000 (11:05 -0500)]
While parsing for check constraints, ignore newline characters in the check condition
Fixed bug where PostgreSQL reflection of CHECK constraints would fail to
parse the constraint if the SQL text contained newline characters. The
regular expression has been adjusted to accommodate for this case. Pull
request courtesy Eric Borczuk.
Mike Bayer [Wed, 26 Feb 2020 21:51:32 +0000 (16:51 -0500)]
Open up check for relationships that write to the same column
Enhanced logic that tracks if relationships will be conflicting with each
other when they write to the same column to include simple cases of two
relationships that should have a "backref" between them. This means that
if two relationships are not viewonly, are not linked with back_populates
and are not otherwise in an inheriting sibling/overriding arrangement, and
will populate the same foreign key column, a warning is emitted at mapper
configuration time warning that a conflict may arise. A new parameter
:paramref:`.relationship.overlaps` is added to suit those very rare cases
where such an overlapping persistence arrangement may be unavoidable.
Mike Bayer [Tue, 5 Mar 2019 20:37:00 +0000 (15:37 -0500)]
Don't call pre_ping for fresh connection
The pool "pre-ping" feature has been refined to not invoke for a DBAPI
connection that was just opened in the same checkout operation. pre ping
only applies to a DBAPI connection that's been checked into the pool
and is being checked out again.
Albert Tugushev [Wed, 26 Feb 2020 16:09:29 +0000 (11:09 -0500)]
Remove print statement in favor of print() function in docs and examples
<!-- Provide a general summary of your proposed changes in the Title field above -->
### Description
<!-- Describe your changes in detail -->
Remove print statements
### Checklist
<!-- go over following points. check them with an `x` if they do apply, (they turn into clickable checkboxes once the PR is submitted, so no need to do everything at once)
-->
This pull request is:
- [X] A documentation / typographical error fix
- Good to go, no issue or tests are needed
- [ ] A short code fix
- please include the issue number, and create an issue if none exists, which
must include a complete example of the issue. one line code fixes without an
issue and demonstration will not be accepted.
- Please include: `Fixes: #<issue number>` in the commit message
- please include tests. one line code fixes without tests will not be accepted.
- [ ] A new feature implementation
- please include the issue number, and create an issue if none exists, which must
include a complete example of how the feature would look.
- Please include: `Fixes: #<issue number>` in the commit message
- please include tests.
Mike Bayer [Mon, 24 Feb 2020 18:54:37 +0000 (13:54 -0500)]
Deprecate row.keys() for 2.0, not 1.x
row.keys() is used by any use case that applies dict() to
a row. Access of elements by string key is also a 2.0 deprecation
not 1.4 so for rudimental dict(row) support make sure that is all
a 2.0 thing.
Mike Bayer [Mon, 24 Feb 2020 15:44:14 +0000 (10:44 -0500)]
Ensure schema-level table includes annotations in caching
In 29330ec159 we ensured that annotations are part of cache keys.
However we failed to do so for the schema-level Table which
will definitely need to distinguish between ORM and non-ORM
annotated tables when caching, so ensure this is part of the
cache key.
Mike Bayer [Sat, 22 Feb 2020 18:11:20 +0000 (13:11 -0500)]
Ensure descendants of mixins don't become cacheable
HasPrefix / HasSuffixes / SupportsCloneAnnotations exported
a _traverse_internals attribute that does not represent a
complete traversal, meaning non-traversible subclasses would
seem traversible. rename these attributes so that this
does not occur. DML is currently not traversible (will be soon).
Mike Bayer [Sat, 22 Feb 2020 15:22:18 +0000 (10:22 -0500)]
Repair inline flag
In 9fca5d827d we attempted to deprecate the "inline=True" flag
and add a generative inline() method, however failed to include
any tests and the method was implemented incorrectly such that
it would get overwritten with the boolean flag immediately.
Rename the internal "inline" flag to "_inline" and add test
support both for the method as well as deprecated support
for the flag, including a fixture addition to assert the expected
value of the flag as it generally does not affect the
actual compiled SQL string.
- ResultSetMetaData broken out into "simple" and "cursor" versions
for ORM and Core, as well as LegacyCursor version.
- Row now has _mapping attribute that supplies full mapping behavior.
Row and SimpleRow both have named tuple behavior otherwise.
LegacyRow has some mapping features on the tuple which emit
deprecation warnings (e.g. keys(), values(), etc). the biggest
change for mapping->tuple is the behavior of __contains__ which
moves from testing of "key in row" to "value in row".
- ResultProxy breaks into ResultProxy and FutureResult (interim),
the latter has the newer APIs. Made available to dialects
using execution options.
- internal reflection methods and most tests move off of implicit
Row mapping behavior and move to row._mapping, result.mappings()
method using future result
- a new strategy system for cursor handling replaces the various
subclasses of RowProxy
- some execution context adjustments. We will leave EC in but
refined things like get_result_proxy() and out parameter handling.
Dialects for 1.4 will need to adjust from get_result_proxy()
to get_result_cursor_strategy(), if they are using this method
- out parameter handling now accommodated by get_out_parameter_values()
EC method. Oracle changes for this. external dialect for
DB2 for example will also need to adjust for this.
- deprecate case_insensitive flag for engine / result, this
feature is not used
mapping-methods on Row are deprecated, and replaced with
Row._mapping.<meth>, including:
row.keys() -> use row._mapping.keys()
row.items() -> use row._mapping.items()
row.values() -> use row._mapping.values()
key in row -> use key in row._mapping
int in row -> use int < len(row)
Mike Bayer [Sun, 2 Feb 2020 18:24:40 +0000 (13:24 -0500)]
Deprecate connection branching
The :meth:`.Connection.connect` method is deprecated as is the concept of
"connection branching", which copies a :class:`.Connection` into a new one
that has a no-op ".close()" method. This pattern is oriented around the
"connectionless execution" concept which is also being removed in 2.0.
As part of this change we begin to move the internals away from
"connectionless execution" overall. Remove the "connectionless
execution" concept from the reflection internals and replace with
explicit patterns at the Inspector level.
Mike Bayer [Thu, 20 Feb 2020 14:01:36 +0000 (09:01 -0500)]
Remove unnecessary tuple; prepare for "iterator" verbiage
Remove a tuple surrounding a generator expression that
is immediately iterated in any case. Additionally
note that the bulk methods can likely accept non-list
objects such as arbitrary iterables, however without test
coverage this is not yet guaranteed; use the term "sequence"
for now.
Also added a warmup to a cache key profiling test to get
consistent results.
Mike Bayer [Mon, 17 Feb 2020 20:21:59 +0000 (15:21 -0500)]
Pass DDLCompiler IdentifierPreparer to visit_ENUM
Fixed issue where the "schema_translate_map" feature would not work with a
PostgreSQL native enumeration type (i.e. :class:`.Enum`,
:class:`.postgresql.ENUM`) in that while the "CREATE TYPE" statement would
be emitted with the correct schema, the schema would not be rendered in
the CREATE TABLE statement at the point at which the enumeration was
referenced.
Mike Bayer [Mon, 17 Feb 2020 16:51:33 +0000 (11:51 -0500)]
Limit non-backend critical profiling tests to SQLite
issues with backend-specific profiling should be limited
to tests that are explcitly against resultset, compiler, etc.
MySQL in particular has an often varying callcount that isn't
worth running these tests against nor is it worth profiling
them for other backends like Oracle and SQL Server.
Also add the REQUIRE_SQLALCHEMY_CEXT flag to
the regen_callcounts.tox.ini script, which is part of some review
somewhere but is needed here to generate callcounts correctly.
Add a "warmup" phase for some of the ORM tests for join conditions
that have varying profile counts based on whether mappings have been
used already or not; profiling should always be against the
"warmed up" version of a function.
Gord Thompson [Thu, 13 Feb 2020 19:14:42 +0000 (12:14 -0700)]
Replace engine.execute w/ context manager (step1)
First (baby) step at replacing engine.execute
calls in test code with the new preferred way
of executing. MSSQL was targeted because it was
the easiest for me to test locally.
Mike Bayer [Mon, 17 Feb 2020 14:41:59 +0000 (09:41 -0500)]
Further refine fractional seconds datetimeoffset fixture
in 55f6d61e85b7f16df0b77f1c55a4fb051cd696e3 we still
forgot to accommodate for Python 3 timezone constructor
rejecting fractional minutes so the test further needs lambdas
to prevent the constructor from invoking for Python versions
less than 3.7
Mike Bayer [Thu, 13 Feb 2020 20:43:05 +0000 (15:43 -0500)]
Fractional seconds starts at Python 3.7
CI didn't notice that the fractional seconds in the new SQL Server
DATETIMEOFFSET test are not available on Python 3.6. It was
inadvertently assumed this was a Python 2 incompatibility.
Mike Bayer [Thu, 13 Feb 2020 20:41:04 +0000 (15:41 -0500)]
Document new LIMIT/OFFSET support; support subquery ORDER BY
An adjustment to the original commit for the fix
to #5084 in ab1799a2a1951fe8f188b6395fde04a233a3ac0d, correctly
rendering ORDER BY for subqueries with the new syntax.
Mike Bayer [Thu, 13 Feb 2020 17:48:26 +0000 (12:48 -0500)]
Improve ResultProxy/Row documentation before the API change
We'd like to merge Ieb9085e9bcff564359095b754da9ae0af55679f0,
however the documentation in that change should be based off
of more comprehensive documentation than what we have already.
Add the notion of "row" to the tutorial and document all
methods. This will also be backported at least to 1.3
in terms of RowProxy.
Mike Bayer [Fri, 24 Jan 2020 19:07:24 +0000 (14:07 -0500)]
Create initial future package, RemovedIn20Warning
Reorganization of Select() is the first major element
of the 2.0 restructuring. In order to start this we need
to first create the new Select constructor and apply legacy
elements to the old one. This in turn necessitates
starting up the RemovedIn20Warning concept which itself
need to refer to "sqlalchemy.future", so begin to establish
this basic framework. Additionally, update the
DML constructors with the newer no-keyword style. Remove
the use of the "pending deprecation" and fix Query.add_column()
deprecation which was not acting as deprecated.
Mike Bayer [Tue, 11 Feb 2020 17:51:46 +0000 (12:51 -0500)]
Begin to disallow back_populates with viewonly=True
A viewonly=True relationship should not be mutated and ideally
mutation itself would raise an error, but we're not there yet.
Warn when a viewonly is to be the target of a back_populates
as this only means that it should be locally mutated, which
by definition will not work as expected because post-flush
it will deliver doubled results, due to its state not being
reset.
Setting a relationship to viewonly=True which is also the target of a
back_populates or backref configuration will now emit a warning and
eventually be disallowed. back_populates refers specifically to mutation
of an attribute or collection, which is disallowed when the attribute is
subject to viewonly=True. The viewonly attribute is not subject to
persistence behaviors which means it will not reflect correct results
when it is locally mutated.
Gord Thompson [Mon, 3 Feb 2020 23:42:45 +0000 (16:42 -0700)]
Fix handling of None as parameter for a datetimeoffset column
Fixed issue where the :class:`.mssql.DATETIMEOFFSET` type would not
accommodate for the ``None`` value, introduced as part of the series of
fixes for this type first introduced in :ticket:`4983`, :ticket:`5045`.
Additionally, added support for passing a backend-specific date formatted
string through this type, as is typically allowed for date/time types on
most other DBAPIs.
Mike Bayer [Mon, 10 Feb 2020 20:38:39 +0000 (15:38 -0500)]
Rework combination exclusions
The technique arrived at for doing exclusions inside of combinations
relies upon comparing all the arguments in a particular combination
to some set of combinations that were gathered as having
"exclusions". This logic is actually broken for the
case where the @testing.combinations has an "id", but if we fix
that, we still have the issue of all the arguments being
compared, which is complicated and also doesn't work for the
case of a py2/py3 incompatibility like a timezone that has
fractional minutes or seconds in it. It's also not clear
if a @testing.combinations that uses lambdas will work either
(maybe it does though because lambdax == lambdax compares...).
anyway, this patch reworks it so that we hit this on the decorator
side instead, where we add our own decorator and go through
the extra effort to create a decorator that accepts an extra
argument of "exclusions" which we can then check in a way that
is local to the whole pytest @combinations thing in the first place.
The only difficulty is that pytest is very sneaky about looking
at the test function so we need to make sure __wrapped__ isn't
set when doing this.
Mike Bayer [Sat, 8 Feb 2020 19:53:21 +0000 (14:53 -0500)]
Fixes for public_factory and mysql/pg dml functions
* ensure that the location indicated by public_factory is
importable
* adjust all of sqlalchemy.sql.expression locations to be correct
* support the case where a public_factory is against a function
that has another public_factory already, and already replaced the
__init__ on the target class
* Use mysql.insert(), postgresql.insert(), don't include .dml in the
class path.
Mike Bayer [Fri, 7 Feb 2020 22:55:07 +0000 (17:55 -0500)]
Vendor inspect.formatannotation
Vendored the ``inspect.formatannotation`` function inside of
``sqlalchemy.util.compat``, which is needed for the vendored version of
``inspect.formatargspec``. The function is not documented in cPython and
is not guaranteed to be available in future Python versions.
Elkin [Wed, 5 Feb 2020 14:51:14 +0000 (09:51 -0500)]
MSSQL 2014 OFFSET/FETCH syntax support
SQL Server OFFSET and FETCH keywords are now used for limit/offset, rather
than using a window function, for SQL Server versions 11 and higher. TOP is
still used for a query that features only LIMIT. Pull request courtesy
Elkin.
Mike Bayer [Thu, 6 Feb 2020 15:26:50 +0000 (10:26 -0500)]
Document SQLite "mixed binary" behavior
The Pysqlite driver can store a string value with
or without an indicator that the value is to be retrieved
as bytes or as a unicode string object. To suit the
use case where a SQLite database has mixed values on a row
by row basis, provide a recipe for a MixedBinary datatype.
Mike Bayer [Tue, 4 Feb 2020 21:46:49 +0000 (16:46 -0500)]
Add second section detailing cascade_backrefs to backref section
We only have docs for "cascade_backrefs" in the session->cascades
documentation, when this really should be mentioned in the chapter
that's all about backrefs. Add a similar section and link to the
original for further detail.
Mike Bayer [Sat, 1 Feb 2020 17:27:09 +0000 (12:27 -0500)]
Do away with pool._refs
This collection was added only for the benefit of unit tests
and is unnecessary for the pool to function. As SQLAlchemy 2.0
will be removing the automatic handling of connections that are
garbage collection, remove this collection so that we ultimately
don't need a weakref handler to do anything within the pool.
The handler will do nothing other than emit a warning that
a connection was dereferenced without being explicitly returned
to the pool, invalidated, or detached.
Mike Bayer [Fri, 31 Jan 2020 16:10:08 +0000 (11:10 -0500)]
Warn for runid changing in load events; add restore_load_context flag
Added a new flag :paramref:`.InstanceEvents.restore_load_context` and
:paramref:`.SessionEvents.restore_load_context` which apply to the
:meth:`.InstanceEvents.load`, :meth:`.InstanceEvents.refresh`, and
:meth:`.SessionEvents.loaded_as_persistent` events, which when set will
restore the "load context" of the object after the event hook has been
called. This ensures that the object remains within the "loader context"
of the load operation that is already ongoing, rather than the object being
transferred to a new load context due to refresh operations which may have
occurred in the event. A warning is now emitted when this condition occurs,
which recommends use of the flag to resolve this case. The flag is
"opt-in" so that there is no risk introduced to existing applications.
The change additionally adds support for the ``raw=True`` flag to
session lifecycle events.
Mike Bayer [Tue, 28 Jan 2020 21:44:53 +0000 (16:44 -0500)]
Raise for unexpected polymorphic identity
A query that is against an mapped inheritance subclass which also uses
:meth:`.Query.select_entity_from` or a similar technique in order to
provide an existing subquery to SELECT from, will now raise an error if the
given subquery returns entities that do not correspond to the given
subclass, that is, they are sibling or superclasses in the same hierarchy.
Previously, these would be returned without error. Additionally, if the
inheritance mapping is a single-inheritance mapping, the given subquery
must apply the appropriate filtering against the polymorphic discriminator
column in order to avoid this error; previously, the :class:`.Query` would
add this criteria to the outside query however this interferes with some
kinds of query that return other kinds of entities as well.
Mike Bayer [Tue, 28 Jan 2020 17:34:06 +0000 (12:34 -0500)]
Accommodate for base class when adjusting path for with_polymorphic
Fixed an additional regression in the same area as that of :ticket:`5080`
introduced in 1.3.0b3 via :ticket:`4468` where the ability to create a
joined option across a :func:`.with_polymorphic` into a relationship
against the base class of that with_polymorphic, and then further into
regular mapped relationships would fail as the base class component would
not add itself to the load path in a way that could be located by the
loader strategy. The changes applied in :ticket:`5080` have been further
refined to also accommodate this scenario.
Gord Thompson [Mon, 27 Jan 2020 21:49:28 +0000 (16:49 -0500)]
Add py3.8, py3.9 token to setup.py
Fixes: #5113
<!-- Provide a general summary of your proposed changes in the Title field above -->
### Description
Add py3.8 and py3.9 tokens to setup.py
### Checklist
<!-- go over following points. check them with an `x` if they do apply, (they turn into clickable checkboxes once the PR is submitted, so no need to do everything at once)
-->
This pull request is:
- [ ] A documentation / typographical error fix
- Good to go, no issue or tests are needed
- [x] A short code fix
- please include the issue number, and create an issue if none exists, which
must include a complete example of the issue. one line code fixes without an
issue and demonstration will not be accepted.
- Please include: `Fixes: #<issue number>` in the commit message
- please include tests. one line code fixes without tests will not be accepted.
- [ ] A new feature implementation
- please include the issue number, and create an issue if none exists, which must
include a complete example of how the feature would look.
- Please include: `Fixes: #<issue number>` in the commit message
- please include tests.
Gord Thompson [Mon, 13 Jan 2020 01:08:22 +0000 (20:08 -0500)]
Refactor test provisioning to dialect-level files
Fixes: #5085
<!-- Provide a general summary of your proposed changes in the Title field above -->
Move dialect-specific provisioning code to dialect-level copies of provision.py.
<!-- go over following points. check them with an `x` if they do apply, (they turn into clickable checkboxes once the PR is submitted, so no need to do everything at once)
-->
This pull request is:
- [ ] A documentation / typographical error fix
- Good to go, no issue or tests are needed
- [x] A short code fix
- please include the issue number, and create an issue if none exists, which
must include a complete example of the issue. one line code fixes without an
issue and demonstration will not be accepted.
- Please include: `Fixes: #<issue number>` in the commit message
- please include tests. one line code fixes without tests will not be accepted.
- [ ] A new feature implementation
- please include the issue number, and create an issue if none exists, which must
include a complete example of how the feature would look.
- Please include: `Fixes: #<issue number>` in the commit message
- please include tests.
Federico Caselli [Thu, 23 Jan 2020 22:51:38 +0000 (17:51 -0500)]
Deprecate empty or_() and and_()
Creating an :func:`.and_` or :func:`.or_` construct with no arguments or
empty ``*args`` will now emit a deprecation warning, as the SQL produced is
a no-op (i.e. it renders as a blank string). This behavior is considered to
be non-intuitive, so for empty or possibly empty :func:`.and_` or
:func:`.or_` constructs, an appropriate default boolean should be included,
such as ``and_(True, *args)`` or ``or_(False, *args)``. As has been the
case for many major versions of SQLAlchemy, these particular boolean
values will not render if the ``*args`` portion is non-empty.
As there are some internal cases where an empty and_() construct is used
in order to build an optional WHERE expression, a private
utility function is added to suit this use case.
Gord Thompson [Mon, 20 Jan 2020 20:21:17 +0000 (15:21 -0500)]
Add test requirement: indexes_with_ascdesc
There are some tests for indexes that include DESC in the
columns. Firebird and maybe others don't support this concept,
so put it under a requirement rule.
Mike Bayer [Wed, 22 Jan 2020 21:27:26 +0000 (16:27 -0500)]
InstanceState default path is RootRegistry, not tuple
Fixed regression caused in 1.3.13 by :ticket:`5056` where a refactor of the
ORM path registry system made it such that a path could no longer be
compared to an empty tuple, which can occur in a particular kind of joined
eager loading path. The "empty tuple" use case has been resolved so that
the path registry is compared to a path registry in all cases; the
:class:`.PathRegistry` object itself now implements ``__eq__()`` and
``__ne__()`` methods which will take place for all equality comparisons and
continue to succeed in the not anticipated case that a non-
:class:`.PathRegistry` object is compared, while emitting a warning that
this object should not be the subject of the comparison.