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.
Added "from linting" as a built-in feature to the SQL compiler. This
allows the compiler to maintain graph of all the FROM clauses in a
particular SELECT statement, linked by criteria in either the WHERE
or in JOIN clauses that link these FROM clauses together. If any two
FROM clauses have no path between them, a warning is emitted that the
query may be producing a cartesian product. As the Core expression
language as well as the ORM are built on an "implicit FROMs" model where
a particular FROM clause is automatically added if any part of the query
refers to it, it is easy for this to happen inadvertently and it is
hoped that the new feature helps with this issue.
The original recipe is from:
https://github.com/sqlalchemy/sqlalchemy/wiki/FromLinter
The linter is now enabled for all tests in the test suite as well.
This has necessitated that a lot of the queries be adjusted to
not include cartesian products. Part of the rationale for the
linter to not be enabled for statement compilation only was to reduce
the need for adjustment for the many test case statements throughout
the test suite that are not real-world statements.
This gerrit is adapted from Ib5946e57c9dba6da428c4d1dee6760b3e978dda0.
Mike Bayer [Wed, 22 Jan 2020 16:01:59 +0000 (11:01 -0500)]
Clarify documentation for lazy_loaded_from
This attribute was never available in conjunction with
mapper options, and additionally the use of baked queries
in the lazy loader strategy prevent this attribute from
being reliably available within the before_compile hook
unless baked queries are turned off entirely.
Mike Bayer [Tue, 21 Jan 2020 23:41:48 +0000 (18:41 -0500)]
Reorganize core event modules to avoid import cycles
sqlalchemy.sql.naming was causing a full import of
engine due to the DDLEvents dependency. Break out pool,
DDL and engine events into new modules specific to those
packages; resolve some other import cycles in Core also.
Mike Bayer [Mon, 20 Jan 2020 17:41:22 +0000 (12:41 -0500)]
Adjust natural path to relationship's base mapper for aliased class also
Fixed regression in loader options introduced in 1.3.0b3 via :ticket:`4468`
where the ability to create a loader option using
:meth:`.PropComparator.of_type` targeting an aliased entity that is an
inheriting subclass of the entity which the preceding relationship refers
to would fail to produce a matching path. See also :ticket:`5082` fixed
in this same release which involves a similar kind of issue.
Gord Thompson [Thu, 19 Dec 2019 17:20:39 +0000 (12:20 -0500)]
Improve regex parsing of CHECK constraints for PostgreSQL.
Fixed issue where the PostgreSQL dialect would fail to parse a reflected
CHECK constraint that was a boolean-valued function (as opposed to a
boolean-valued expression).
Mike Bayer [Fri, 17 Jan 2020 22:31:41 +0000 (17:31 -0500)]
Remove jython code, remove all jython / pypy symbols
Removed all dialect code related to support for Jython and zxJDBC. Jython
has not been supported by SQLAlchemy for many years and it is not expected
that the current zxJDBC code is at all functional; for the moment it just
takes up space and adds confusion by showing up in documentation. At the
moment, it appears that Jython has achieved Python 2.7 support in its
releases but not Python 3. If Jython were to be supported again, the form
it should take is against the Python 3 version of Jython, and the various
zxJDBC stubs for various backends should be implemented as a third party
dialect.
Additionally modernized logic that distinguishes between "cpython"
and "pypy" to instead look at platform.python_distribution() which
reliably tells us if we are cPython or not; all booleans which
previously checked for pypy and sometimes jython are now converted
to be "not cpython", this impacts the test suite for tests that are
cPython centric.
Mike Bayer [Fri, 17 Jan 2020 19:31:10 +0000 (14:31 -0500)]
apply asbool reduction to the onclause in join()
The :func:`.true` and :func:`.false` operators may now be applied as the
"onclause" of a :func:`.sql.join` on a backend that does not support
"native boolean" expressions, e.g. Oracle or SQL Server, and the expression
will render as "1=1" for true and "1=0" false. This is the behavior that
was introduced many years ago in :ticket:`2804` for and/or expressions.
Mike Bayer [Tue, 14 Jan 2020 22:32:12 +0000 (17:32 -0500)]
Establish that contains_eager()->alias can be replaced by of_type
One test in test_of_type was creating a cartesian product
because contains_eager() was used with "alias" to refer
to a with_polymorphic(), but the wp was not used with of_type(),
so the pathing did not know that additional entities were present.
while the docs indicate that of_type() should be used, there is no
reason to use "alias" when you are using of_type(). Attempts
to make this automatic don't work as the current usage contract
with "alias" is that the contains_eager() chain can continue
along in terms of the base entities, which is another example
of the implicit swapping of entities for an aliased version of
themselves that really should be entirely marked as deprecated
throughout 1.4 and removed in 2.0.
So instead, add test coverage for the of_type() versions of
things and begin to make the case that we can remove "alias"
entirely, where previously we thought we would only deprecate
the string form.
Mike Bayer [Mon, 13 Jan 2020 18:50:38 +0000 (13:50 -0500)]
Adjust use_mapper_path rule for poly subclasses
We must change the approach from 2734439 as the information
loss is breaking subquery eager loading.
Move the adjustment into a deeper set of logic inside
of path_regsitry. We can distinguish between a path
that will "naturally" build from an aliased entity
at the base, vs. one that will "naturally" build
on all raw mappers, based on if when we observe that
we are being given a with_polymorphic(), if the existing
parent path is already in progress or not.
In general, we prefer paths to have as much of the original
information as possible, and the "natural path" is supposed
to be where the loader lookup stuff happens.
Mike Bayer [Fri, 10 Jan 2020 18:16:43 +0000 (13:16 -0500)]
Fixes for table-bound version_id_col against mapped selectable
Fixed bug where a versioning column specified on a mapper against a
:func:`.select` construct where the version_id_col itself were against the
underlying table would incur additional loads when accessed, even if the
value were locally persisted by the flush. The actual fix is a result of
the changes in :ticket:`4617`, by fact that a :func:`.select` object no
longer has a ``.c`` attribute and therefore does not confuse the mapper
into thinking there's an unknown column value present.
Fixed bug in ORM versioning feature where assignment of an explicit
version_id for a counter configured against a mapped selectable where
version_id_col is against the underlying table would fail if the previous
value were expired; this was due to the fact that the mapped attribute
would not be configured with active_history=True.
Mike Bayer [Fri, 10 Jan 2020 18:16:43 +0000 (13:16 -0500)]
Integrate mapper-level version_id_col with versioned_history
as the versioned_history example supplies an integer version
counter for the purposes of generating an audit trail, this
counter is also suited to be used for optimistic concurrency
detection using the version_id_col feature. Build upon
the test that was first added in ac54ba0f2d8df5a76b6852841b6b3321c0e6c0e2
to provide a flag and some basic documentation.
Mike Bayer [Fri, 10 Jan 2020 15:30:13 +0000 (10:30 -0500)]
Alter unique bound parameter key on deserialize
Fixed bug in sqlalchemy.ext.serializer where a unique
:class:`.BindParameter` object could conflict with itself if it were
present in the mapping itself, as well as the filter condition of the
query, as one side would be used against the non-deserialized version and
the other side would use the deserialized version. Logic is added to
:class:`.BindParameter` similar to its "clone" method which will uniquify
the parameter name upon deserialize so that it doesn't conflict with its
original.
Mike Bayer [Tue, 7 Jan 2020 02:06:10 +0000 (21:06 -0500)]
Set use_mapper_path=True for with_poly subentities
Fixed regression in joined eager loading introduced in 1.3.0b3 via
:ticket:`4468` where the ability to create a joined option across a
:func:`.with_polymorphic` into a polymorphic subclass using
:meth:`.RelationshipProperty.of_type` and then further along regular mapped
relationships would fail as the polymorphic subclass would not add itself
to the load path in a way that could be located by the loader strategy. A
tweak has been made to resolve this scenario.
Mike Bayer [Mon, 6 Jan 2020 19:09:01 +0000 (14:09 -0500)]
Support GenericFunction.name passed as a quoted_name
A function created using :class:`.GenericFunction` can now specify that the
name of the function should be rendered with or without quotes by assigning
the :class:`.quoted_name` construct to the .name element of the object.
Prior to 1.3.4, quoting was never applied to function names, and some
quoting was introduced in :ticket:`4467` but no means to force quoting for
a mixed case name was available. Additionally, the :class:`.quoted_name`
construct when used as the name will properly register its lowercase name
in the function registry so that the name continues to be available via the
``func.`` registry.
Mike Bayer [Wed, 1 Jan 2020 23:24:03 +0000 (18:24 -0500)]
Enable F821
In Ia63a510f9c1d08b055eef62cf047f1f427f0450c we introduced
"lambda combinations" which use a bit of function closure inspection
in order to allow for testing combinations that make use of symbols that
come from test fixtures, or from the test itself.
Two problems. One is that we can't use F821 flake8 rule without either
adding lots of noqas, skipping the file, or adding arguments to the
lambdas themselves that are then populated, which makes for a very
verbose system. The other is that the system is already verbose
with all those lambdas and the magic in use is a non-explicit kind,
hence F821 reminds us that if we can improve upon this, we should.
So let's improve upon it by making it so that the "lambda" is just
once and up front for the whole thing, and let it accept the arguments
directly. This still requires magic, because these test cases need
to resolve at test collection time, not test runtime. But we will
instead substitute a namespace up front that can be coerced into
its desired form within the tests.
Additionally, there's a little bit of py2k compatible type annotations
present; f821 is checking these, so we have to add those imports
also using the TYPE_CHECKING boolean so they don't take place in
py2k.
Mike Bayer [Fri, 3 Jan 2020 17:10:57 +0000 (12:10 -0500)]
Fix cext for Python 2; ensure C extensions build successfully
The C extensions have been broken since cc718cccc0bf8a01abdf4068c
however CI did not find this, because the build degraded to
non-C extensions without failing. Ensure that if cext is set,
there is no fallback to non-cext build if the C extension build
fails.
As C extensions have been silently failing on 2.7 for some commits,
the callcounts also needed to be adjusted for recent performance-related
changes. That in turn required a fix to the profiling decorator
to use signature rewriting in order to support py.test's
fixture mechanism under Python 2, usage introduced under profiling
in 89bf6d80a9.
Mike Bayer [Thu, 2 Jan 2020 17:48:23 +0000 (12:48 -0500)]
Implement explicit autobegin step for Session
The :class:`.Session` object no longer initates a
:class:`.SessionTransaction` object immediately upon construction or after
the previous transaction is closed; instead, "autobegin" logic now
initiates the new :class:`.SessionTransaction` on demand when it is next
needed. Rationale includes to remove reference cycles from a
:class:`.Session` that has been closed out, as well as to remove the
overhead incurred by the creation of :class:`.SessionTransaction` objects
that are often discarded immediately. This change affects the behavior of
the :meth:`.SessionEvents.after_transaction_create` hook in that the event
will be emitted when the :class:`.Session` first requires a
:class:`.SessionTransaction` be present, rather than whenever the
:class:`.Session` were created or the previous :class:`.SessionTransaction`
were closed. Interactions with the :class:`.Engine` and the database
itself remain unaffected.
Heckad [Wed, 1 Jan 2020 19:47:01 +0000 (14:47 -0500)]
Use context managers for threading.Lock()
(zzzeek:) For some reason I thought that threading.Lock() still did
not support context managers, at least in Python 2, however this
does not seem to be the case.
Co-authored-by: Mike Bayer <mike_mp@zzzcomputing.com> Closes: #5069
Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/5069
Pull-request-sha: efeac06dda5afdbe33abcf9b27c8b5b5725c8444
projects / thirdparty / sqlalchemy / sqlalchemy.git / log
