| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Change-Id: Idb7840ff64487ef985087a28bb6e96088e6a392e
References: #8098
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fixed bugs involving the :paramref:`.Table.include_columns` and the
:paramref:`.Table.resolve_fks` parameters on :class:`.Table`; these
little-used parameters were apparently not working for columns that refer
to foreign key constraints.
In the first case, not-included columns that refer to foreign keys would
still attempt to create a :class:`.ForeignKey` object, producing errors
when attempting to resolve the columns for the foreign key constraint
within reflection; foreign key constraints that refer to skipped columns
are now omitted from the table reflection process in the same way as
occurs for :class:`.Index` and :class:`.UniqueConstraint` objects with the
same conditions. No warning is produced however, as we likely want to
remove the include_columns warnings for all constraints in 2.0.
In the latter case, the production of table aliases or subqueries would
fail on an FK related table not found despite the presence of
``resolve_fks=False``; the logic has been repaired so that if a related
table is not found, the :class:`.ForeignKey` object is still proxied to the
aliased table or subquery (these :class:`.ForeignKey` objects are normally
used in the production of join conditions), but it is sent with a flag that
it's not resolvable. The aliased table / subquery will then work normally,
with the exception that it cannot be used to generate a join condition
automatically, as the foreign key information is missing. This was already
the behavior for such foreign key constraints produced using non-reflection
methods, such as joining :class:`.Table` objects from different
:class:`.MetaData` collections.
Fixes: #8100
Fixes: #8101
Change-Id: Ifa37a91bd1f1785fca85ef163eec031660d9ea4d
|
| | |
| |
| |
| |
| | |
Change-Id: I75992af71ba08799a03995178a6e4612c9a7428a
References: #8108
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | | |
Fixes: #8054
Change-Id: Idd7c1bbb7ca39499f53bdf59a63a6a9d65f144a5
|
| |\ \ \
| |_|/
|/| | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
other org changes and some sections from old tutorial
ported to new tutorial.
Change-Id: Ic0fba60ec82fff481890887beef9ed0fa271875a
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
sane_rowcount_w_returning asserts failure, which will only
occur here if the DBAPI actually uses RETURNING.
as SQLite conditionally supports RETURNING which breaks
rowcount support only if present, limit this test to that
case.
Additionally, newer pysqlites will likely fix the issue so
we will probably want to put a sqlite3_version check as well
once that fix is released.
Change-Id: I065aa181eb48363c1024550ae3622486ae0b4a6e
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
As almost every dialect supports RETURNING now, RETURNING
is also made more of a default assumption.
* the default compiler generates a RETURNING clause now
when specified; CompileError is no longer raised.
* The dialect-level implicit_returning parameter now has
no effect. It's not fully clear if there are real world
cases relying on the dialect-level parameter, so we will see
once 2.0 is released. ORM-level RETURNING can be disabled
at the table level, and perhaps "implicit returning" should
become an ORM-level option at some point as that's where
it applies.
* Altered ORM update() / delete() to respect table-level
implicit returning for fetch.
* Since MariaDB doesnt support UPDATE returning, "full_returning"
is now split into insert_returning, update_returning, delete_returning
* Crazy new thing. Dialects that have *both* cursor.lastrowid
*and* returning. so now we can pick between them for SQLite
and mariadb. so, we are trying to keep it on .lastrowid for
simple inserts with an autoincrement column, this helps with
some edge case test scenarios and i bet .lastrowid is faster
anyway. any return_defaults() / multiparams etc then we
use returning
* SQLite decided they dont want to return rows that match in
ON CONFLICT. this is flat out wrong, but for now we need to
work with it.
Fixes: #6195
Fixes: #7011
Closes: #7047
Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/7047
Pull-request-sha: d25d5ea3abe094f282c53c7dd87f5f53a9e85248
Co-authored-by: Mike Bayer <mike_mp@zzzcomputing.com>
Change-Id: I9908ce0ff7bdc50bd5b27722081767c31c19a950
|
| | |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* Add **kwargs to CaseInsensitiveComparator docs
* add kwargs to other operate examples
Change-Id: I70a1e68bca27c2355ad3b7c5bbc538027f112bd9
* missed one entry
Change-Id: Ieb4a18ab6d96e588e9ec7672cfa65fe2fd8301e5
Co-authored-by: Federico Caselli <cfederico87@gmail.com>
|
| |\ \ \ |
|
| | | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | | |
Fixed an issue where :meth:`_sql.GenerativeSelect.fetch` would be
ignored when executing a statement using the ORM.
Fixes: #8091
Change-Id: I6790c7272a71278e90de2529c8bc8ae89e54e288
|
| | | |
| | |
| | | |
Signed-off-by: cuishuang <imcusg@gmail.com>
|
| | | | |
|
| | | |
| | |
| | | |
Leave off the last S for savings!
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* ClassVar for decl fields, add __tablename__
* dataclasses require annotations for all fields. For us,
if no annotation, then skip that field as part of what is
considered to be a "dataclass", as this matches the behavior
of pyright right now. We could alternatively raise on this
use, which is what dataclasses does. we should ask the pep
people
* plain field that's just "str", "int", etc., with no value.
Disallow it unless __allow_unmapped__ is set. If field
has dataclasses.field, Column, None, a value etc, it goes through,
and when using dataclasses mixin all such fields are considered
for the dataclass setup just like a dataclass. Hopefully this
does not have major backwards compat issues. __allow_unmapped__
can be set on the base class, mixins, etc., it's liberal for
now in case people have this problem.
* accommodate for ClassVar, these are not considered at all for
mapping.
Change-Id: Id743aa0456bade9a5d5832796caeecc3dc4accb7
|
| | |
| |
| |
| |
| |
| |
| |
| | |
issues like #8082 suggest users are still not
fully aware of the need to set this parameter
when dealing with detached objects.
Change-Id: I6f389fdbe18b9c977bfb8188fc4732dbd56884d9
|
| |\ \
| |/
|/| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
this allows cast() of a label() to propagate the
proxy key outwards in the same way that it apparently
works at the SQL level.
This is stuffing even more rules into naming so basically
seeing how far we can go without other cases starting
to fail.
Fixes: #8084
Change-Id: I20bd97dae798fee6492334c06934e807d0f269ef
|
| |\ \
| |/
|/| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Added new backend-agnostic :class:`_types.Uuid` datatype generalized from
the PostgreSQL dialects to now be a core type, as well as migrated
:class:`_types.UUID` from the PostgreSQL dialect. Thanks to Trevor Gross
for the help on this.
also includes:
* corrects some missing behaviors in the suite literal fixtures
test where row round trips weren't being correctly asserted.
* fixes some of the ISO literal date rendering added in
952383f9ee0 for #5052 to truncate datetime strings for date/time
datatypes in the same way that drivers typically do for bound
parameters; this was not working fully and wasn't caught by the
broken test fixture
Fixes: #7212
Change-Id: I981ac6d34d278c18281c144430a528764c241b04
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The :meth:`.DialectEvents.handle_error` event is now moved to the
:class:`.DialectEvents` suite from the :class:`.EngineEvents` suite, and
now participates in the connection pool "pre ping" event for those dialects
that make use of disconnect codes in order to detect if the database is
live. This allows end-user code to alter the state of "pre ping". Note that
this does not include dialects which contain a native "ping" method such as
that of psycopg2 or most MySQL dialects.
Fixes: #5648
Change-Id: I353d84a4f66f309d2467b7e67621db6b8c70411e
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Change-Id: Id3fc3019f8eb799aa5adf6ca28e0aeedc0da31dd
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This is so that custom Session and AsyncSession classes
can be typed for these factories. Added appropriate
typevars to `__call__()`, `__enter__()` and other methods
so that a custom Session or AsyncSession subclass is carried
through.
Fixes: #7656
Change-Id: Ia2b8c1f22b4410db26005c3285f6ba3d13d7f0e0
|
| |\ \ \ \ |
|
| | | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Added two new error codes for Oracle disconnect handling to support early
testing of the new "python-oracledb" driver released by Oracle.
Fixes: #8066
Closes: #8065
Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/8065
Pull-request-sha: d630b8457a1d29b7a1354ccc6d5e2956eea865f6
Change-Id: Ib14dbb888597b1087b1bb7c505ccad59df226177
(cherry picked from commit 2bf00472bfafd8fd0cca5b4fe55ff4faf1a1279e)
(cherry picked from commit 8564e2abf97795819f655a70b19b3bc820729c79)
|
| |\ \ \ \ |
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
An informative error is raised for the use case where
:meth:`.Insert.from_select` is being passed a "compound select" object such
as a UNION, yet the INSERT statement needs to append additional columns to
support Python-side or explicit SQL defaults from the table metadata. In
this case a subquery of the compound object should be passed.
Fixes: #8073
Change-Id: Ic4a5dbf84ec49d2451901be05cb9cf6ae93f02b7
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* Update declarative_styles.rst
Update docs to new style usage of attrs.
This is the default since December 2021.
While the old style still works, the newer one looks much nicer and is likely to be dominant pretty quickly. Imho.
* Update declarative_styles.rst
* Update declarative_styles.rst
|
| | |/
|/|
| |
| |
| |
| |
| |
| | |
Closes: #8075
Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/8075
Pull-request-sha: 34e5eaf3870f89c9c38ffe81121fa1b42e363752
Change-Id: Iab8cdc9f8da68ac955eea75efeba263d0a9dcb7b
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fixed issue where using a :func:`_orm.column_property` construct containing
a subquery against an already-mapped column attribute would not correctly
apply ORM-compilation behaviors to the subquery, including that the "IN"
expression added for a single-table inherits expression would fail to be
included.
This fix involves a few tweaks in the ORM adaptation logic,
including a missing "parententity" adaptation on the mapper
side. The specific mechanics here have a lot of moving parts
so we will continue to add tests to assert these cases. In
particular a more complete test for issue #2316 is added
that was relying upon the deannotate happening here.
Fixes: #8064
Change-Id: Ia85dd12dcf6e7c002b30de4a27d7aa66cb3cd20e
|
| |\ \ \ |
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
in 296c84313ab29bf9599634f3 for #5653 we generalized Oracle's
parameter escaping feature into the compiler, so that it could also
work for PostgreSQL. The compiler used quoted names within parameter
dictionaries, which then led to the complexity that all functions
which interpreted keys from the compiled_params dict had to
also quote the param names to use the dictionary. This
extra complexity was not added to the ORM peristence.py however,
which led to the versioning id feature being broken as well as
other areas where persistence.py relies on naming schemes present
in context.compiled_params. It also was not added to the
"processors" lookup which led to #8053, that added this escaping
to that part of the compiler.
To both solve the whole problem as well as simplify the compiler
quite a bit, move the actual application of the escaped names
to be as late as possible, when default.py builds the final list
of parameters. This is more similar to how it worked previously
where OracleExecutionContext would be late-applying these
escaped names. This re-establishes context.compiled_params as
deterministically named regardless of dialect in use and moves
out the complexity of the quoted param names to be only at the
cursor.execute stage.
Fixed bug, likely a regression from 1.3, where usage of column names that
require bound parameter escaping, more concretely when using Oracle with
column names that require quoting such as those that start with an
underscore, or in less common cases with some PostgreSQL drivers when using
column names that contain percent signs, would cause the ORM versioning
feature to not work correctly if the versioning column itself had such a
name, as the ORM assumes certain bound parameter naming conventions that
were being interfered with via the quotes. This issue is related to
:ticket:`8053` and essentially revises the approach towards fixing this,
revising the original issue :ticket:`5653` that created the initial
implementation for generalized bound-parameter name quoting.
Fixes: #8056
Change-Id: I57b064e8f0d070e328b65789c30076f6a0ca0fef
|
| |/ /
| |
| |
| |
| |
| |
| |
| | |
Fix issue where a password with a leading "{" would
result in login failure.
Fixes: #8062
Change-Id: If91c2c211937b5eac89b8d525c22a19b0a94c5c4
|
| | |
| |
| |
| |
| |
| |
| | |
note that UUID will be generalized into core with #7212.
Fixes: #6402
Change-Id: I90f0052ca74367c2c2f1ce2f8a90e81d173d1430
|
| |/
|
|
|
|
|
| |
We have a lot of mappings with like ForeignKey(A.id)
so this needs to be included.
Change-Id: I8ac4211fb09720f093fe7f6353f365ee1d7faaae
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| | |
this count seems to have grown a bit. can look into
the cause, but at the moment we need CI to pass.
Change-Id: Iea1e4900d5c5d3f80e7ce400a2b9cc1f313cef4c
|
| |\ \
| |/
|/| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fixed SQL compiler issue where the "bind processing" function for a bound
parameter would not be correctly applied to a bound value if the bound
parameter's name were "escaped". Concretely, this applies, among other
cases, to Oracle when a :class:`.Column` has a name that itself requires
quoting, such that the quoting-required name is then used for the bound
parameters generated within DML statements, and the datatype in use
requires bind processing, such as the :class:`.Enum` datatype.
Fixes: #8053
Change-Id: I39d060a87e240b4ebcfccaa9c535e971b7255d99
|
| |\ \
| |/
|/| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
ROLLBACK TO SAVEPOINT is re-enabled
in https://github.com/tlocke/pg8000/issues/111.
we still have to add savepoint support to our fixture that
deletes from tables without checking for them.
this is inconvenient but not incorrect.
Change-Id: I2f4a0a3e18db93c3e6794ade9b0fee33d2e4b7dc
|
| | |
| |
| |
| |
| |
| |
| |
| | |
this test is failing on CI with "##foo does not exist",
so hypothesize there's some kind of race condition with
global temp table names.
Change-Id: I8c6c26a7fda70f67735ce20af67373c311e48731
|
