| Commit message (Collapse) | Author | Age | Files | Lines |
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Applied a sweep through all included dialects to ensure names that contain
single or double quotes are properly escaped when querying system tables,
for all :class:`.Inspector` methods that accept object names as an argument
(e.g. table names, view names, etc). SQLite and MSSQL contained two
quoting issues that were repaired.
Fixes: #5456
Change-Id: I3bc98806f5166f3d82275650079ff561446f2aef
|
|\ \ |
|
| |/
| |
| |
| |
| |
| |
| |
| | |
this concept is not clear that we offer real
DBAPI autocommit everywhere. backport 1.3 with edits
as well
Change-Id: I2e8328b7fb6e1cdc5453ab29c94276f60c7ca149
|
|\ \
| |/
|/| |
|
| |
| |
| |
| |
| |
| |
| | |
They previously would use the linux profiles, but recently some discrepancies in
the function call count on osx would make the tests fail.
Change-Id: Ifdfdca1676972de4179f59cdaae196f6805d4a21
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
mock in python 2.7 / 3.8 seems to have an "args" accessor
but in prior python 3 versions this is not the case,
so this is likely a recent addition to "mock" but wasn't
present in the python3 vendored versions.
Change-Id: Iff8afe75e891c9658c7c7b577831fefd5986940b
|
| |
| |
| |
| |
| |
| |
| |
| | |
in the move to setup.cfg at
9ca81f5f79498356c4f3387c17edda0ed3dad451 we put the wrong
README file.
Change-Id: I25193d248e325e9473f26901925f91bef54ca07a
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
many more to come.
One issue is that references to documentation sections
inside of decorator-configured deprecation warnings will
also generate a meaningless token when the runtime warning
is emitted. It would be nice to improve upon this somehow.
Change-Id: I16b214b3d310850bbfb0d9ade70235f5a9735eba
|
|\ \
| |/
|/| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is kind of a mixed bag of all kinds to help get us
to 1.4 betas. The documentation stuff is a work in
progress. Lots of other relatively small changes to
APIs and things. More commits will follow to continue
improving the documentation and transitioning to the
1.4/2.0 hybrid documentation. In particular some refinements
to Session usage models so that it can match Engine's
scoping / transactional patterns, and a decision to
start moving away from "subtransactions" completely.
* add select().from_statement() to produce FromStatement in an
ORM context
* begin referring to select() that has "plugins" for the few edge
cases where select() will have ORM-only behaviors
* convert dynamic.AppenderQuery to its own object that can use
select(), though at the moment it uses Query to support legacy
join calling forms.
* custom query classes for AppenderQuery are replaced by
do_orm_execute() hooks for custom actions, a separate gerrit
will document this
* add Session.get() to replace query.get()
* Deprecate session.begin->subtransaction. propose within the
test suite a hypothetical recipe for apps that rely on this
pattern
* introduce Session construction level context manager,
sessionmaker context manager, rewrite the whole top of the
session_transaction.rst documentation. Establish context manager
patterns for Session that are identical to engine
* ensure same begin_nested() / commit() behavior as engine
* devise all new "join into an external transaction" recipe,
add test support for it, add rules into Session so it
just works, write new docs. need to ensure this doesn't
break anything
* vastly reduce the verbosity of lots of session docs as
I dont think people read this stuff and it's difficult
to keep current in any case
* constructs like case(), with_only_columns() really need
to move to *columns, add a coercion rule to just change
these.
* docs need changes everywhere I look. in_() is not in
the Core tutorial? how do people even know about it?
Remove tons of cruft from Select docs, etc.
* build a system for common ORM options like populate_existing
and autoflush to populate from execution options.
* others?
Change-Id: Ia4bea0f804250e54d90b3884cf8aab8b66b82ecf
|
|\ \ |
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
<!-- Provide a general summary of your proposed changes in the Title field above -->
### Description
<!-- Describe your changes in detail -->
- Update the test so it looks at computed_default_table instead of
computed_column_table.
- Stop inspecting autoincrement; instead directly check for
default/non-default values for the relevant columns.
Fixes: #5414
### 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.
**Have a nice day!**
Closes: #5417
Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/5417
Pull-request-sha: 5918af6abb991e6d2322ea4252e56d456da628dc
Change-Id: Id9484ae7f297735345016be5b7461325825503da
|
|/
|
|
|
|
|
|
| |
The commit for I1654befe9eb1c8b8e7fc0784bdbe64284614f0ea #5357
runs the test on all Python 3 versions, however we need to limit
at least python 3.6 for this.
Change-Id: Ie86b78bbfd8c7bd013ff9aa7f8905328d792c1b3
|
|
|
|
|
|
|
|
|
|
| |
the memory tests are solely responsible for the largest chunk of
time and CPU energy taken up in running the tests. Regressions
in this area are nonexistent unless major changes are being
taken up. Try to revert them to False and see if a single
gerrit job can perhaps run these.
Change-Id: Ibaead2d1c0a76f1339bee63652a8aead689e8b75
|
|
|
|
|
|
|
|
| |
the recent change to select() apparently seems to have
been merged with other statements in the test_update_delete
test that was still using the old term.
Change-Id: I6be3eb148249bfcf08aae19efcad89803c69c658
|
|\
| |
| |
| | |
Change-Id: Ib052efc33ddd58d38e16c0cc721abee668b861d5
|
| | |
|
|\ \
| | |
| | |
| | | |
Change-Id: Ibab5889b14c546a8c43c5eaf88ed5d1f53713880
|
| | | |
|
|\ \ \ |
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Several weeks of using the future_select() construct
has led to the proposal there be just one select() construct
again which features the new join() method, and otherwise accepts
both the 1.x and 2.x argument styles. This would make
migration simpler and reduce confusion.
However, confusion may be increased by the fact that select().join()
is different Current thinking is we may be better off
with a few hard behavioral changes to old and relatively unknown APIs
rather than trying to play both sides within two extremely similar
but subtly different APIs. At the moment, the .join() thing seems
to be the only behavioral change that occurs without the user
taking any explicit steps. Session.execute() will still
behave the old way as we are adding a future flag.
This change also adds the "future" flag to Session() and
session.execute(), so that interpretation of the incoming statement,
as well as that the new style result is returned, does not
occur for existing applications unless they add the use
of this flag.
The change in general is moving the "removed in 2.0" system
further along where we want the test suite to fully pass
even if the SQLALCHEMY_WARN_20 flag is set.
Get many tests to pass when SQLALCHEMY_WARN_20 is set; this
should be ongoing after this patch merges.
Improve the RemovedIn20 warning; these are all deprecated
"since" 1.4, so ensure that's what the messages read.
Make sure the inforamtion link is on all warnings.
Add deprecation warnings for parameters present and
add warnings to all FromClause.select() types of methods.
Fixes: #5379
Fixes: #5284
Change-Id: I765a0b912b3dcd0e995426427d8bb7997cbffd51
References: #5159
|
|\ \ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The deprecated logic to move order_by expressions
up into the columns clause needed adjustment to accommodate
for a more deeply-wrapped structure when desc() + label()
are combined in an order by column. This structure
now comes from coercions in 1.4. it's not clear to me
at the moment why it's different from 1.3 but
this shouldn't really matter.
Fixes: #5443
Change-Id: If909a86f715992318d7aa283603197f7711f1d3b
|
|\ \ \ \
| |/ / /
|/| | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Added a ``**kw`` argument to the :meth:`.DeclarativeMeta.__init__` method.
This allows a class to support the :pep:`487` metaclass hook
``__init_subclass__``. Pull request courtesy Ewen Gillies.
Fixes: #5357
Closes: #5363
Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/5363
Pull-request-sha: 0ad05a768316cba03a4d312ab39d3e8fbca7ac54
Change-Id: I1654befe9eb1c8b8e7fc0784bdbe64284614f0ea
|
|\ \ \ \ |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
### Description
Added a semicolon to improve the clarity of warning message. I actually had a table named `backend`, and thought it was involved!
While updating the code, I noticed no test that directly tests for this warning message. There are tests for the `Can't sort tables for DROP;` prefix of this message and the `exc.CircularDependencyError`; and some tests for the `exc.CircularDependencyError` message itself. I couldn't find any test for this particular message though. (Just thought I'd bring that up)
No issue created, because this is minor.
Closes: #5431
Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/5431
Pull-request-sha: 87fb5733ff4fc1a13dd94277716814ea852f654c
Change-Id: I87a504d30a7dd5155c34f7d7f30b2116d0d3cd3f
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
1. move all discussion of how to customize connection
to the engines.rst section. have the section in pooling.rst
point to engines.
2. ensure all of the common use cases for connection modification
are listed out in order of level of modification. the use
case of modifying an existing connection is separate from that of
modifying how connect is called; ensure that poolevents.connect
is referred to just as prominently as dialectevents.do_connect.
3. completely replace any discussion of create_engine.creator, as this
hook does not offer anything beyond what do_connect() does.
"creator" is more about using a Pool object directly without an
Engine, which is no longer a documented use case.
Change-Id: Ibe366d2a6e63eb420a6136fdc71ce0fb545edf8f
|
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
A few places have logic that assumes the top-level statement
is the actual UPDATE or DELETE which is not the case with a
lambda. Ensure the correct object is used. This
fixes issues specific to both "fetch" strategy
as well as "evaluate" strategy.
Fixes: #5442
Change-Id: Ic9cc01c696c3c338d5bc79688507e6717c4c169b
|
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
PyODBC apparently pools connections by default and this
is a module-wide setting only. Documenent that this happens
and how to disable it.
Fixes: #5440
Change-Id: I415bda7beb2211c66991b6c804b0ddb4d79e427f
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The coercions system allows us to add in lambdas as arguments
to Core and ORM elements without changing them at all. By allowing
the lambda to produce a deterministic cache key where we can also
cheat and yank out literal parameters means we can move towards
having 90% of "baked" functionality in a clearer way right in
Core / ORM.
As a second step, we can have whole statements inside the lambda,
and can then add generation with __add__(), so then we have
100% of "baked" functionality with full support of ad-hoc
literal values.
Adds some more short_selects tests for the moment for comparison.
Other tweaks inside cache key generation as we're trying to
approach a certain level of performance such that we can
remove the use of "baked" from the loader strategies.
As we have not yet closed #4639, however the caching feature
has been fully integrated as of
b0cfa7379cf8513a821a3dbe3028c4965d9f85bd, we will also
add complete caching documentation here and close that issue
as well.
Closes: #4639
Fixes: #5380
Change-Id: If91f61527236fd4d7ae3cad1f24c38be921c90ba
|
| | |
| | |
| | |
| | | |
Change-Id: I8b10309e47b07065893f6f41dfdbd67ad3e96bad
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
we need to know all version / database information for questions
as well and users should be encouraged to follow MCVE form
if possible.
Change-Id: Ic3a4c4dbb021069b7765aa351a4d4d18a821160d
|
|/ /
| |
| |
| |
| | |
Fixes: #5432
Change-Id: I22e4ba3a7131165c551bcba7e377fa45d71d70e0
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We want to use Oracle version >=7 for all platforms,
but <8 for Python 2.
Similarly, we want to use mysqlclient >= 1.4.0 for all
platforms, but < 2 for Python 2.
Have tox.ini defer to setup.cfg for DBAPIs.
We're not testing mysql-connector-python right now so remove
this from tox.ini.
Change-Id: I02611937da71d2950545e42c34f0b9798478e2a8
|
|\ \ \ |
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Renamed the :meth:`_schema.Table.tometadata` method to
:meth:`_schema.Table.to_metadata`. The previous name remains with a
deprecation warning.
Updated the "decorate" utility function to support decoration
of functions that include non-builtins as default values.
Moves test for deprecated "databases" package into
test/dialect/test_deprecations.py
Fixes: #5413
Fixes: #5426
Change-Id: I6ed899871c935f9e46360127c17ccb7cf97cea6e
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
To eliminate any remaining confusion, clarify that
DATETIME (as well as DateTime) and TIMESTAMP are treated
similarly with the MySQL dialect regarding ON UPDATE.
Change-Id: I222522440706902d5d2d11e670e76f16000438e0
References: #5427
|
|\ \ \ |
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
loader options can now make a deterministic cache key based
on the structure they are given, and this accommodates for
aliased classes as well so that these cache keys are now
"safe". Have baked query call upon
the regular cache key method.
Change-Id: Iaa2ef4064cfb16146f415ca73080f32003dd830d
|
|\ \ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fixes: #5423
Change-Id: I716f8de17c49d7eefbbce5ddd9da203bfc9fe47f
|
|\ \ \ \
| | | | |
| | | | |
| | | | | |
when running an update"
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
running an update
### Description
There was a bug in 1.3.8 that allowed passing a `BinaryExpression` to `Session().query`. I assume it was fixed in https://github.com/sqlalchemy/sqlalchemy/commit/3ab2364e78641c4f0e4b6456afc2cbed39b0d0e6 since now it raises:
```
sqlalchemy.exc.ArgumentError: subject table for an INSERT, UPDATE or DELETE expected, got <sqlalchemy.sql.elements.BinaryExpression object at 0x7f3d90426370>.
```
I'm just adding a test that ensures the behavior. Fixes: [4556](https://github.com/sqlalchemy/sqlalchemy/issues/4556)
### 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.
**Have a nice day!**
Closes: #5419
Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/5419
Pull-request-sha: af7601dff1a0dce94802627a9fe2398be60d8186
Change-Id: Ic1a9075e7e8520510964fdd3d7ac14fba550110c
|
| |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
MySQL 8 no longer generates the DEFAULT or ON UPDATE
clauses for TIMESTAMP by default, hence users will begin to hit
this regularly. add warnings that this non-standard SQL is not
accommodated by server_onupdate and docuemnt the workaround
used in issues such as #4652.
Fixes: #5427
Change-Id: Ie048dcc91c648dd0b80ed395208c1d665b6c968b
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Have observed CI failure with windows where not all
three connections got pulled out at the same time here
as the threads got serialized. make sure all three
connections get used.
Change-Id: Ic2f7c7de1069358d95035f90c725c7dddd4f34d4
|
|\ \ \ \
| |_|/ /
|/| | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Build on #5401 to allow the ORM to take advanage
of executemany INSERT + RETURNING.
Implemented the feature
updated tests
to support INSERT DEFAULT VALUES, needed to come up with
a new syntax for compiler INSERT INTO table (anycol) VALUES (DEFAULT)
which can then be iterated out for executemany.
Added graceful degrade to plain executemany for PostgreSQL <= 8.2
Renamed EXECUTEMANY_DEFAULT to EXECUTEMANY_PLAIN
Fix issue where unicode identifiers or parameter names wouldn't
work with execute_values() under Py2K, because we have to
encode the statement and therefore have to encode the
insert_single_values_expr too.
Correct issue from #5401 to support executemany + return_defaults
for a PK that is explicitly pre-generated, meaning we aren't actually
getting RETURNING but need to return it from compiled_parameters.
Fixes: #5263
Change-Id: Id68e5c158c4f9ebc33b61c06a448907921c2a657
|