Mike Bayer [Fri, 28 Oct 2022 16:20:22 +0000 (12:20 -0400)]
update rel/fk FAQ entry
this entry still made the assumptions of behavior before
ticket #3061, that accessing a non-initialized scalar attribute
on a pending object would populate the attribute with None.
It also used the word "initialize" when referring to a persistent
object which is a misleading term, it's "loaded", even though
in this example it's "loading" the value of None.
Fix up the language to be more consistent with the #3061 change.
Mike Bayer [Thu, 27 Oct 2022 13:28:02 +0000 (09:28 -0400)]
apply basic escaping to anon_labels unconditionally
Fixed issue which prevented the :func:`_sql.literal_column` construct from
working properly within the context of a :class:`.Select` construct as well
as other potential places where "anonymized labels" might be generated, if
the literal expression contained characters which could interfere with
format strings, such as open parenthesis, due to an implementation detail
of the "anonymous label" structure.
Mike Bayer [Wed, 26 Oct 2022 17:27:21 +0000 (13:27 -0400)]
ensure inherited mapper attrs not interpreted as plain dataclass fields
Fixed issue in new dataclass mapping feature where a column declared on the
decalrative base / abstract base / mixin would leak into the constructor
for an inheriting subclass under some circumstances.
Mike Bayer [Mon, 24 Oct 2022 15:29:36 +0000 (11:29 -0400)]
reconcile Mapper properties ordering against mapped Table
Changed a fundamental configuration behavior of :class:`.Mapper`, where
:class:`_schema.Column` objects that are explicitly present in the
:paramref:`_orm.Mapper.properties` dictionary, either directly or enclosed
within a mapper property object, will now be mapped within the order of how
they appear within the mapped :class:`.Table` (or other selectable) itself
(assuming they are in fact part of that table's list of columns), thereby
maintaining the same order of columns in the mapped selectable as is
instrumented on the mapped class, as well as what renders in an ORM SELECT
statement for that mapper. Previously (where "previously" means since
version 0.0.1), :class:`.Column` objects in the
:paramref:`_orm.Mapper.properties` dictionary would always be mapped first,
ahead of when the other columns in the mapped :class:`.Table` would be
mapped, causing a discrepancy in the order in which the mapper would
assign attributes to the mapped class as well as the order in which they
would render in statements.
The change most prominently takes place in the way that Declarative
assigns declared columns to the :class:`.Mapper`, specifically how
:class:`.Column` (or :func:`_orm.mapped_column`) objects are handled
when they have a DDL name that is explicitly different from the mapped
attribute name, as well as when constructs such as :func:`_orm.deferred`
etc. are used. The new behavior will see the column ordering within
the mapped :class:`.Table` being the same order in which the attributes
are mapped onto the class, assigned within the :class:`.Mapper` itself,
and rendered in ORM statements such as SELECT statements, independent
of how the :class:`_schema.Column` was configured against the
:class:`.Mapper`.
Mike Bayer [Tue, 25 Oct 2022 14:22:14 +0000 (10:22 -0400)]
raise for non-Load opt passed to options()
Fixed the exception that's raised when the
:func:`_orm.with_loader_criteria` option is attempted to be used within a
specific loader path, like in loader.options().
:func:`_orm.with_loader_criteria` is only intended to be used at the top
level.
Mike Bayer [Mon, 24 Oct 2022 23:24:11 +0000 (19:24 -0400)]
add Oracle-specific parameter escapes for expanding params
Fixed issue where bound parameter names, including those automatically
derived from similarly-named database columns, which contained characters
that normally require quoting with Oracle would not be escaped when using
"expanding parameters" with the Oracle dialect, causing execution errors.
The usual "quoting" for bound parameters used by the Oracle dialect is not
used with the "expanding parameters" architecture, so escaping for a large
range of characters is used instead, now using a list of characters/escapes
that are specific to Oracle.
Mike Bayer [Sun, 23 Oct 2022 23:24:54 +0000 (19:24 -0400)]
skip ad-hoc properties within subclass_load_via_in
Fixed issue where "selectin_polymorphic" loading for inheritance mappers
would not function correctly if the :param:`_orm.Mapper.polymorphic_on`
parameter referred to a SQL expression that was not directly mapped on the
class.
Mike Bayer [Sun, 23 Oct 2022 14:34:33 +0000 (10:34 -0400)]
test support for has_table()->view; backport to 1.4
For 1.4 only; in 2.0 this just refines the test suite a bit.
Fixed regression which occurred throughout the 1.4 series where the
:meth:`.Inspector.has_table` method, which historically reported on views
as well, stopped working for SQL Server. The issue is not present in the
2.0 series which uses a different reflection architecture. Test support is
added to ensure ``has_table()`` remains working per spec re: views.
Mike Bayer [Fri, 21 Oct 2022 16:37:04 +0000 (12:37 -0400)]
Only convert Range for sqlalchemy Range object
Refined the new approach to range objects described at :ref:`change_7156`
to accommodate driver-specific range and multirange objects, to better
accommodate both legacy code as well as when passing results from raw SQL
result sets back into new range or multirange expressions.
Mike Bayer [Fri, 21 Oct 2022 04:11:10 +0000 (00:11 -0400)]
allow legacy forms with __allow_unmapped__
Improved support for legacy 1.4 mappings that use annotations which don't
include ``Mapped[]``, by ensuring the ``__allow_unmapped__`` attribute can
be used to allow such legacy annotations to pass through Annotated
Declarative without raising an error and without being interpreted in an
ORM runtime context. Additionally improved the error message generated when
this condition is detected, and added more documentation for how this
situation should be handled. Unfortunately the 1.4 WARN_SQLALCHEMY_20
migration warning cannot detect this particular configurational issue at
runtime with its current architecture.
Mike Bayer [Thu, 20 Oct 2022 16:28:29 +0000 (12:28 -0400)]
move API docs downwards
Sphinx 5.3 (compared to 5.1.1) is now putting all the autodoc
names into the TOC. So we have to start being more careful
to make sure API docs are well below narrative docs, because
this new style is a wall of text. i dont yet see any options
to turn it off, but it does seem like a good improvement, just makes
doc organization a more difficult endeavor.
Mike Bayer [Thu, 20 Oct 2022 16:05:33 +0000 (12:05 -0400)]
collect annotation earlier for mapped_column present
Fixed issue with new dataclass mapping feature where arguments passed to
the dataclasses API could sometimes be mis-ordered when dealing with mixins
that override :func:`_orm.mapped_column` declarations, leading to
initializer problems.
the change made here is specific to the test case given which regards
mapped_column() most specifically. cases that involve relationship()
etc. are not tested here, however mapped_column() is the only attribute
that's implicit without an instance given on the right side, and is also
most common for mixins. not clear if there are more issues in this
area, however it appears that we need only adjust the order in which we
accommodate grabbing the annotations in order to affect how dataclasses
sees the class; that is, we have control over ``__annotations__`` here
so dont have to worry about ``cls.__dict__``.
Mike Bayer [Wed, 19 Oct 2022 13:41:44 +0000 (09:41 -0400)]
more many-to-one typing
since we are typing centric, note this configuration
as we have just supported in #8668.
Note also I am just taking "backref" out of the basic
version of the docs here totally, this doc is already
a lot to read / take in without making it even more
confusing; backref still has an entirely dedicated
docs page which can have all the additional behaviors
of backref() described.
Additionally, get other "optional" forms to work including
``cls | None`` and ``Union[cls, None]``.
Mike Bayer [Wed, 19 Oct 2022 13:17:03 +0000 (09:17 -0400)]
rename tables to _table for basic relationships
the names "parent" / "child" are confusing for new users
in that they are used for table names as well as
"back_populates='parent'", use a disambiguated name.
In this change, there's now overlap between the
variable named "association_table" and the table name
"association_table". not sure of a better naming system.
Mike Bayer [Wed, 19 Oct 2022 01:01:05 +0000 (21:01 -0400)]
de-optionalize union types to support Optional for m2o
Fixed bug in new ORM typed declarative mappings where we did not include
the ability to use ``Optional[]`` in the type annotation for a many-to-one
relationship, even though this is common.
Mike Bayer [Tue, 18 Oct 2022 17:25:06 +0000 (13:25 -0400)]
call super().__init_subclass__(); support GenericAlias
Improved the :class:`.DeclarativeBase` class so that when combined with
other mixins like :class:`.MappedAsDataclass`, the order of the classes may
be in either order.
Added support for mapped classes that are also ``Generic`` subclasses,
to be specified as a ``GenericAlias`` object (e.g. ``MyClass[str]``)
within statements and calls to :func:`_sa.inspect`.
Mike Bayer [Tue, 18 Oct 2022 13:44:37 +0000 (09:44 -0400)]
further qualify pyodbc setinputsizes types for long stirngs
Fixed regression caused by SQL Server pyodbc change :ticket:`8177` where we
now use ``setinputsizes()`` by default; for VARCHAR, this fails if the
character size is greater than 4000 (or 2000, depending on data) characters
as the incoming datatype is NVARCHAR, which has a limit of 4000 characters,
despite the fact that VARCHAR can handle unlimited characters. Additional
pyodbc-specific typing information is now passed to ``setinputsizes()``
when the datatype's size is > 2000 characters. The change is also applied
to the :class:`.JSON` type which was also impacted by this issue for large
JSON serializations.
The :class:`.Sequence` construct restores itself to the DDL behavior it
had prior to the 1.4 series, where creating a :class:`.Sequence` with
no additional arguments will emit a simple ``CREATE SEQUENCE`` instruction
**without** any additional parameters for "start value". For most backends,
this is how things worked previously in any case; **however**, for
MS SQL Server, the default value on this database is
``-2**63``; to prevent this generally impractical default
from taking effect on SQL Server, the :paramref:`.Sequence.start` parameter
should be provided. As usage of :class:`.Sequence` is unusual
for SQL Server which for many years has standardized on ``IDENTITY``,
it is hoped that this change has minimal impact.
Mike Bayer [Mon, 17 Oct 2022 19:09:01 +0000 (15:09 -0400)]
update SEQUENCE docs ahead of default change
for backport to 1.4 as well, remove references to
Firebird, and also revert "associate Sequence with MetaData"
step as this is not needed usually, just note that schema
is not shared. encourage users to use IDENTITY instead.
Mike Bayer [Mon, 17 Oct 2022 15:53:07 +0000 (11:53 -0400)]
simplify unmapped col eval fallback
Removed the warning that emits when using ORM-enabled update/delete
regarding evaluation of columns by name, first added in :ticket:`4073`;
this warning actually covers up a scenario that otherwise could populate
the wrong Python value for an ORM mapped attribute depending on what the
actual column is, so this deprecated case is removed. In 2.0, ORM enabled
update/delete uses "auto" for "synchronize_session", which should do the
right thing automatically for any given UPDATE expression.
Mike Bayer [Sun, 16 Oct 2022 22:30:44 +0000 (18:30 -0400)]
repair type qualify in _ServerDefaultType; other pyright tweaks
as we haven't done full pylance / pyright strict typing internally,
some of the things pyright reports on specifically will leak
out into user code, such as this mapped_column() issue.
So we will have to look more closely at pyright strict
mode going forward for the release.
Fixed typing issue where pylance strict mode would report "partially
unknown" datatype for the :func:`_orm.mapped_column` construct.
Also repaired a trailing comma and pyright complaining about overloads
for orm.composite.
Mike Bayer [Sat, 15 Oct 2022 19:20:21 +0000 (15:20 -0400)]
accommodate arbitrary embedded params in insertmanyvalues
Fixed bug in new "insertmanyvalues" feature where INSERT that included a
subquery with :func:`_sql.bindparam` inside of it would fail to render
correctly in "insertmanyvalues" format. This affected psycopg2 most
directly as "insertmanyvalues" is used unconditionally with this driver.
Mike Bayer [Sat, 15 Oct 2022 15:12:25 +0000 (11:12 -0400)]
disable isort in pyproject.toml
disable isort, for IDEs that just default isort to be turned on, e.g. vscode.
we use flake8-import-order for import sorting, using zimports to actually
reformat code. isort is nicer in many ways but doesn't have our
"import *" fixer and also is not 100% compatible with flake8-import-order.
Mike Bayer [Tue, 11 Oct 2022 21:01:43 +0000 (17:01 -0400)]
implement autobegin=False option
Added new parameter :paramref:`_orm.Session.autobegin`, which when set to
``False`` will prevent the :class:`_orm.Session` from beginning a
transaction implicitly. The :meth:`_orm.Session.begin` method must be
called explicitly first in order to proceed with operations, otherwise an
error is raised whenever any operation would otherwise have begun
automatically. This option can be used to create a "safe"
:class:`_orm.Session` that won't implicitly start new transactions.
As part of this change, also added a new status variable
:class:`_orm.SessionTransaction.origin` which may be useful for event
handling code to be aware of the origin of a particular
:class:`_orm.SessionTransaction`.
Mike Bayer [Mon, 10 Oct 2022 18:03:04 +0000 (14:03 -0400)]
warn for no polymorphic identity w/ poly hierarchy
A warning is emitted when attempting to configure a mapped class within an
inheritance hierarchy where the mapper is not given any polymorphic
identity, however there is a polymorphic discriminator column assigned.
Such classes should be abstract if they never intend to load directly.
Mike Bayer [Tue, 11 Oct 2022 18:22:40 +0000 (14:22 -0400)]
enable check same thread for aiosqlite
to do this we have to invent our own isolation level
setter based on their current internals. however
now we can ensure thread-safe access. we are trying
to resolve an issue where test suite on CI seems to fail
around the same time each time.
Mike Bayer [Fri, 7 Oct 2022 18:03:16 +0000 (14:03 -0400)]
rename MappedCollection and related
For consistency with the prominent ORM concept :class:`_orm.Mapped`, the
names of the dictionary-oriented collections,
:func:`_orm.attribute_mapped_collection`,
:func:`_orm.column_mapped_collection`, and :class:`_orm.MappedCollection`,
are changed to :func:`_orm.attribute_keyed_dict`,
:func:`_orm.column_keyed_dict` and :class:`_orm.KeyFuncDict`, using the
phrase "dict" to minimize any confusion against the term "mapped". The old
names will remain indefinitely with no schedule for removal.
Docs here are also updated for typing as we can type
these collections as ``Mapped[dict[str, cls]]``, don't need
KeyFuncDict / MappedCollection for these
Mike Bayer [Fri, 7 Oct 2022 15:25:08 +0000 (11:25 -0400)]
dont mutate bind_arguments incoming dictionary
The :paramref:`_orm.Session.execute.bind_arguments` dictionary is no longer
mutated when passed to :meth:`_orm.Session.execute` and similar; instead,
it's copied to an internal dictionary for state changes. Among other
things, this fixes and issue where the "clause" passed to the
:meth:`_orm.Session.get_bind` method would be incorrectly referring to the
:class:`_sql.Select` construct used for the "fetch" synchronization
strategy, when the actual query being emitted was a :class:`_dml.Delete` or
:class:`_dml.Update`. This would interfere with recipes for "routing
sessions".
Mike Bayer [Mon, 26 Sep 2022 18:38:44 +0000 (14:38 -0400)]
implement write-only colletions, typing for dynamic
For 2.0, we provide a truly "larger than memory collection"
implementation, a write-only collection that will never
under any circumstances implicitly load the entire
collection, even during flush.
This is essentially a much more "strict" version
of the "dynamic" loader, which in fact has a lot of
scenarios that it loads the full backing collection
into memory, mostly defeating its purpose.
Typing constructs are added that support
both the new feature WriteOnlyMapping as well as the
legacy feature DynamicMapping. These have been
integrated with "annotion based mapping" so that
relationship() uses these annotations to configure
the loader strategy as well.
additional changes:
* the docs triggered a conflict in hybrid's
"transformers" section, this section is hard-coded
to Query using a pattern that doesnt seem to have
any use and isn't part of the current select()
interface, so just removed this section
* As the docs for WriteOnlyMapping are very long,
collections.rst is broken up into two pages now.
Mike Bayer [Thu, 29 Sep 2022 16:56:23 +0000 (12:56 -0400)]
reorganize Mapped[] super outside of MapperProperty
We made all the MapperProperty classes a subclass
of Mapped[] to allow declarative mappings to name
Mapped[] on the left side. this was cheating a bit because
MapperProperty is not actually a descriptor, and the mapping
process replaces the object with InstrumentedAttribute at
mapping time, which is the actual Mapped[] descriptor.
But now in I6929f3da6e441cad92285e7309030a9bac4e429d we
are considering making the "cheating" a little more extensive
by putting DynamicMapped / WriteOnlyMapped in Relationship's
hierarchy, which need a flat out "type: ignore" to work.
Instead of pushing more cheats into the core classes, move
out the "Declarative"-facing versions of these classes to be
typing only: Relationship, Composite, Synonym, and MappedSQLExpression
added for ColumnProperty. Keep the internals expressed on the
old names, RelationshipProperty, CompositeProperty, SynonymProperty,
ColumnProprerty, which will remain "pure" with fully correct typing.
then have the typing only endpoints be where the "cheating"
and "type: ignores" have to happen, so that these are more or less
slightly better forms of "Any".
Make if_exists and if_not_exists flags on ddl statements match compiler
Added ``if_exists`` and ``if_not_exists`` parameters for all "Create" /
"Drop" constructs including :class:`.CreateSequence`,
:class:`.DropSequence`, :class:`.CreateIndex`, :class:`.DropIndex`, etc.
allowing generic "IF EXISTS" / "IF NOT EXISTS" phrases to be rendered
within DDL. Pull request courtesy Jesse Bakker.
John Bodley [Fri, 30 Sep 2022 01:58:58 +0000 (21:58 -0400)]
adjust MySQL view reflection for non-standard MySQL variants
Adjusted the regular expression used to match "CREATE VIEW" when
testing for views to work more flexibly, no longer requiring the
special keyword "ALGORITHM" in the middle, which was intended to be
optional but was not working correctly. The change allows view reflection
to work more completely on MySQL-compatible variants such as StarRocks.
Pull request courtesy John Bodley.
Mike Bayer [Mon, 3 Oct 2022 01:22:11 +0000 (21:22 -0400)]
the future is here
the autodoc for the "future" Engine / Connection were removed,
so all these links weren't working. Replace all _future
for these with _engine. There was just one _future pointing
to select, changed that separately.
Mike Bayer [Sun, 2 Oct 2022 02:24:38 +0000 (22:24 -0400)]
add disable doctest tag for autodoc test suite
ahead of trying to get everything formatted, some more
flexibility so that we can use doctest for all
python + sql code, while still being able to tell the
test suite to not run doctests on a sample. All of the
"non-console python with SQL" in the docs is because I was
showing an example that I didn't want tested.
Mike Bayer [Fri, 30 Sep 2022 20:58:26 +0000 (16:58 -0400)]
fix "entry points"
the formatting here wasn't round tripping without manually
adjusting the indentation. this suggests that "check" mode
is not doing the exact same thing as "write". maybe
file.write_text() is changing something.
projects / thirdparty / sqlalchemy / sqlalchemy.git / log
