| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
these are failing on the github runners because 3.5 doesnt
have the async keywords.
Change-Id: I9c58d38f8d7595313b7648b9840b334da8238bd0
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
since 1.3 doesn't have updated pg8000 support nor
asyncpg support it needs to stay on the previous
TOX_POSTGRESQL variable, so make a new one that will
have the newer drivers in it.
Change-Id: I19739f8da1231db975a046f12af5eefc9636cd4a
|
| | |
| | |
| | |
| | | |
Change-Id: Ie47a9e9377858641f2f8e038133be27dc9aacd64
|
|\ \ \ |
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Using the approach introduced at
https://gist.github.com/zzzeek/6287e28054d3baddc07fa21a7227904e
We can now create asyncio endpoints that are then handled
in "implicit IO" form within the majority of the Core internals.
Then coroutines are re-exposed at the point at which we call
into asyncpg methods.
Patch includes:
* asyncpg dialect
* asyncio package
* engine, result, ORM session classes
* new test fixtures, tests
* some work with pep-484 and a short plugin for the
pyannotate package, which seems to have so-so results
Change-Id: Idbcc0eff72c4cad572914acdd6f40ddb1aef1a7d
Fixes: #3414
|
|\ \ \
| |/ /
|/| | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The fix for #5470 didn't actually take into account that
the "distinct" logic in query was also doubling up the criteria.
Added many more tests. the 1.3 version here will be different
than 1.4 as the regression is not quite the same.
Fixes: #5470
Change-Id: I16a23917cab175761de9c867d9d9ac55031d9b97
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The ``importlib_metadata`` library is used to scan for setuptools
entrypoints rather than pkg_resources. as importlib_metadata is a small
library that is included as of Python 3.8, the compatibility library is
installed as a dependency for Python versions older than 3.8.
Unfortunately setuptools "attr:" is broken because it tries to import
the module; seems like this is fixed as part of
https://github.com/pypa/setuptools/pull/1753 however this is too recent
to rely upon for now.
Added a new dialect token "mariadb" that may be used in place of "mysql" in
the :func:`_sa.create_engine` URL. This will deliver a MariaDB dialect
subclass of the MySQLDialect in use that forces the "is_mariadb" flag to
True. The dialect will raise an error if a server version string that does
not indicate MariaDB in use is received. This is useful for
MariaDB-specific testing scenarios as well as to support applications that
are hardcoding to MariaDB-only concepts. As MariaDB and MySQL featuresets
and usage patterns continue to diverge, this pattern may become more
prominent.
Fixes: #5400
Fixes: #5496
Change-Id: I330815ebe572b6a9818377da56621397335fa702
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The fix in 180ae7c1a53385f72b0047496ac001ec5099cc3e
didn't do much as the code was not preserving parameter
order at all, in fact. Reworked stmt_parameters to be
delivered in the correct order up front and preserve
throughout crud.py which was not being done at all
before.
Fixes: #5510
Change-Id: I0795c71df73005a25d1bbf216732d41b41e11a5f
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The issue of Result.fetchXXX() methods returning Row
objects unless filtering is applied will not provide a
clear enough API story when type annotations are applied,
so break out scalars/mappings into separate wrapper objects.
this makes some things more intuitive and other things a little
more bumpy. however the return type story is now clearer.
Fixes: #5503
Change-Id: I629a061823179680dc0723559183859a67ea4db1
|
|\ \ \
| |/ /
|/| | |
|
| | |
| | |
| | |
| | |
| | | |
Fixes: #5411
Change-Id: Ib0c53f5ed3f9d3ff0586580c9a9cce73b4b870f4
|
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| | |
The test for the parameter fix in c0685e5f41 was not working
deterministically on Python 2, so use ordered_values(), however
a second issue in ordered_values() was assuming each element was a
column, so also test for array-assignment expressions with
ordered_values.
Change-Id: I944c72a52700ffb4ab5ae1a83ae21f1efc84b505
|
|/
|
|
|
|
|
|
| |
reword the sorting in terms of the actual behavior,
put correct changed version
References: #5494
Change-Id: I725338526afe28454910d029c153e4476f8c686f
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes related to rendering of complex UPDATE DML
which was not correctly preserving positional parameter
order in conjunction with DML features that are only known
to work on the PostgreSQL database. Both pg8000
and asyncpg use positional parameters which is why these
issues are suddenly apparent.
crud.py now takes on the task of rendering the column
expressions for SET or VALUES so that for the very unusual
case that the column expression is a compound expression
that includes a bound parameter (namely an array index),
the bound parameter order is preserved.
Additionally, crud.py passes through the positional_names
keyword argument into bindparam_string() which is necessary
when CTEs are being rendered, as PG supports complex
CTE / INSERT / UPDATE scenarios.
Change-Id: I7f03920500e19b721636b84594de78a5bfdcbc82
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adjusted the dialect initialization process such that the
:meth:`_engine.Dialect.on_connect` is not called a second time on the first
connection. The hook is called first, then the
:meth:`_engine.Dialect.initialize` is called if that connection is the
first for that dialect, then no more events are called. This eliminates
the two calls to the "on_connect" function which can produce very difficult
debugging situations.
Fixes: #5497
Change-Id: Icefc2e884e30ee7b4ac84b99dc54bf992a6085e3
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Initially to distinsuish between arm and x86_64
architecture, expand out the profile key to include
machine, system, python impl in all cases.
Ref: #5436
Change-Id: I7e48f0462ba7d9c680b2dac45ce7b0cf709b9b22
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fixed issue where the
:paramref:`_engine.Connection.execution_options.schema_translate_map`
feature would not take effect when the :meth:`_schema.Sequence.next_value`
function function for a :class:`_schema.Sequence` were used in the
:paramref:`_schema.Column.server_default` parameter and the create table
DDL were emitted.
Fixes: #5500
Change-Id: I74a9fa13d22749d06c8202669f9ea220d9d984d9
|
| |/
|/|
| |
| |
| | |
Fixes: #5407
Change-Id: Ia0965dbc88d744cded5c23021898388f2cf95f8d
|
|/
|
|
|
|
|
|
|
|
|
|
|
| |
Adjusted the workings of the :meth:`_orm.Mapper.all_orm_descriptors`
accessor to represent the attributes in the order that they are located in
a deterministic way, assuming the use of Python 3.6 or higher which
maintains the sorting order of class attributes based on how they were
declared. This sorting is not guaranteed to match the declared order of
attributes in all cases however; see the method documentation for the exact
scheme.
Fixes: #5494
Change-Id: I6ee8d4ace3eb8b3f7c9c0f2a3d7e27b5f62abfd3
|
|
|
|
| |
Change-Id: I8bdf7c3271b8284ab82e01558024f933e1ee7b49
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* major additions to 1.4 migration doc; removed additional
verbosity regarding caching methodology and reorganized the
doc to present itself more as a "what's changed" guide
* as we now have a path for asyncio, update that doc so that
we aren't spreading obsolete information
* updates to the 2.0 migration guide with latest info, however
this is still an architecture doc and not a migration guide
yet, will need further rework.
* start really talking about 1.x vs. 2.0 style everywhere. Querying
is most of the docs so this is going to be a prominent
theme, start getting it to fit in
* Add introductory documentation for ORM example sections as these
are too sparse
* new documentation for do_orm_execute(), many separate sections,
adding deprecation notes to before_compile() and similar
* new example suites to illustrate do_orm_execute(),
with_loader_criteria()
* modernized horizontal sharding examples and added a separate
example to distinguish between multiple databases and single
database w/ multiple tables use case
* introducing DEEP ALCHEMY, will use zzzeeksphinx 1.1.6
* no name for the alchemist yet however the dragon's name
is Flambé
Change-Id: Id6b5c03b1ce9ddb7b280f66792212a0ef0a1c541
|
|\ \
| |/ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Added the ability to add arbitrary criteria to the ON clause generated
by a relationship attribute in a query, which applies to methods such
as :meth:`_query.Query.join` as well as loader options like
:func:`_orm.joinedload`. Additionally, a "global" version of the option
allows limiting criteria to be applied to particular entities in
a query globally.
Documentation is minimal at this point, new examples will
be coming in a subsequent commit.
Some adjustments to execution options in how they are represented
in the ORMExecuteState as well as well as a few ORM tests that
forgot to get merged in a preceding commit.
Fixes: #4472
Change-Id: I2b8fc57092dedf35ebd16f6343ad0f0d7d332beb
|
|\ \
| |/
|/| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
MySQL 8.0.19 has some changes to how it reports on display widths
for int types (seems like it omits it in some cases), and also
no longer cares about the length for YEAR. Another adjustment
to the ordering of constraints reported in one case also.
At least one CI machine is at 8.0.21 now.
Change-Id: Ie2101bed3ad75dcbb62cd05abe95ef14ad895cf5
|
|/
|
|
|
|
|
|
|
| |
Building on newly robust lambdas in
I29a513c98917b1d503abfdd61e6b6e8800851aa8,
convert key loading off of the "baked" system so that baked
is no longer used by the ORM.
Change-Id: I3abfb45dd6e50f84f29d39434caa0b550ce27864
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
in order to accommodate relationship loaders
with lambda caching, a lot more is needed. This is
a full refactor of the lambda system such that it
now has two levels of caching; the first level caches what
can be known from the __code__ element, then the next level
of caching is against the lambda itself and the contents
of __closure__. This allows for the elements inside
the lambdas, like columns and entities, to change and
then be part of the cache key. Lazy/selectinloads' use of
baked queries had to add distinct cache key elements,
which was attempted here but overall things needed to be
more robust than that.
This commit is broken out from the very long and sprawling
commit at Id6b5c03b1ce9ddb7b280f66792212a0ef0a1c541 .
Change-Id: I29a513c98917b1d503abfdd61e6b6e8800851aa8
|
|
|
|
|
|
|
|
|
| |
Added MariaDB code 1927 to the list of "disconnect" codes, as recent
MariaDB versions apparently use this code when the database server was
stopped.
Fixes: #5493
Change-Id: I63f1d692f36cb0411ead278556e3f8c64ab72ea4
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The behavior of the :paramref:`_orm.relationship.cascade_backrefs` flag
will be reversed in 2.0 and set to ``False`` unconditionally, such that
backrefs don't cascade save-update operations from a forwards-assignment to
a backwards assignment. A 2.0 deprecation warning is emitted when the
parameter is left at its default of ``True`` at the point at which such a
cascade operation actually takes place. The new behavior can be
established as always by setting the flag to ``False`` on a specific
:func:`_orm.relationship`, or more generally can be set up across the board
by setting the the :paramref:`_orm.Session.future` flag to True.
Additionally in the interests of expediency, this commit will also
move Session away from making use of bound metadata if the future=True
flag is set. An application that sets future=True should ideally
have to change as little else as possible for full 2.0 behavior.
Fixes: #5150
Change-Id: I490d1d61f09c62ffc2de983208aeed25dfe48aec
|
| |
| |
| |
| | |
Change-Id: I8315cfef6e5c4b87d64fc770998a1229cc690870
|
| |
| |
| |
| |
| |
| |
| |
| | |
Ideally this would be a per-execution option, or Pyodbc
could perhaps run the data in chunks.
Fixes: #5334
Change-Id: If4a11b312346b8e4c2b8cd38840b3a2ba56dec3b
|
|\ \ |
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Remove lookup logic that attempts to locate a dialect for a type,
just use StrSQLTypeCompiler.
Cleaned up the internal ``str()`` for datatypes so that all types produce a
string representation without any dialect present, including that it works
for third-party dialect types without that dialect being present. The
string representation defaults to being the UPPERCASE name of that type
with nothing else.
Fixes: #4262
Change-Id: I02149e8a1ba1e7336149e962939b07ae0df83c6b
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Per https://gitlab.com/pycqa/flake8-docstrings/-/issues/36#note_199635329
flake8-docstrings has repaired the pydocstyle issue as of
1.3.1, so unpin pydocstyle.
Change-Id: I117a5df58ff6c5a4087c433ab817ad305df6a17b
|
|\ \ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
- in create wheel set minimum versions of setuptools and wheel to avoid
failure in python 3.5 with metadata configured in setup.cfg
- update action versions
- test also cext in the pull requests
Change-Id: Iaa5e4e4000c7faa688b51f2f41428c7dd7cae9c3
|
| |_|/
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fixes: #5482
All supported python versions provide 'uuid' module.
Closes: #5483
Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/5483
Pull-request-sha: fc32498a8b639ff21d5898100592782826d2c6dd
Change-Id: I8b41b811da7576f724353425dad5d6f581641b4b
|
|\ \ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
MySQL claims it doesn't require FROM DUAL for no
FROM clause even though the issue at #5481 locates
a case which requires one. See if FROM DUAL the same
way as Oracle without attempting to guess is potentially
feasible.
Fixes: #5481
Change-Id: I2a28876c10a8ce2d121cd344dcdd837db321d4ab
|
|\ \ \ \
| |_|_|/
|/| | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Update :paramref:`_orm.relationship.sync_backref` flag in a relationship
to make it implicitly set to False in ``viewonly=True`` relationships,
preventing synchronization events in all cases.
References: #5237
Change-Id: Ib02b228a1b6e66b5ffd4540af776ac8f759c9a48
|
| | | |
| | | |
| | | |
| | | | |
Change-Id: I863df033cae9bda4ce96d446a92984ae82797565
|