Added support for the SQL ``CREATE TABLE ... AS SELECT`` construct via the
new :class:`_sql.CreateTableAs` DDL construct and the
:meth:`_sql.SelectBase.into` method. The new construct allows creating a
table directly from the results of a SELECT statement, with support for
options such as ``TEMPORARY`` and ``IF NOT EXISTS`` where supported by the
target database. Pull request courtesy Greg Jarzab.
Fixes: #4950Closes: #12860
Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/12860
Pull-request-sha: 7de8a109b8
Change-Id: Id9c8e4a3c520ffc61de1e48e331b6220e3d52fc9
Added new generalized aggregate function ordering to functions via the
:func:`_functions.FunctionElement.aggregate_order_by` method, which
receives an expression and generates the appropriate embedded "ORDER BY" or
"WITHIN GROUP (ORDER BY)" phrase depending on backend database. This new
function supersedes the use of the PostgreSQL
:func:`_postgresql.aggregate_order_by` function, which remains present for
backward compatibility. To complement the new parameter, the
:paramref:`_functions.aggregate_strings.order_by` which adds ORDER BY
capability to the :class:`_functions.aggregate_strings` dialect-agnostic
function which works for all included backends. Thanks much to Reuven
Starodubski with help on this patch.
Co-authored-by: Mike Bayer <mike_mp@zzzcomputing.com>
Fixes: #12853Closes: #12856
Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/12856
Pull-request-sha: d93fb591751227eb1f96052ea3ad449f511f70b3
Change-Id: I8eb41ff2d57695963a358b5f0017ca9372f15f70
Fixed regression in PostgreSQL dialect where JSONB subscription syntax
would generate incorrect SQL for JSONB-returning functions, causing syntax
errors. The dialect now properly wraps function calls and expressions in
parentheses when using the ``[]`` subscription syntax, generating
``(function_call)[index]`` instead of ``function_call[index]`` to comply
with PostgreSQL syntax requirements.
Fixes: #12778
Change-Id: If1238457e6bba6a933023b26519a41aa5de4dbcd
### Description
Small updates for Oracle Database dialect documentation.
- prefer python-oracledb over cx_Oracle
- Prefer the product name 'Oracle Database' over the company name 'Oracle'
- update links
- modernize
This is a refresh of existing content.
I decided the apparently now duplicated sections between cx_Oracle and python-oracledb were justified for clarity due to the inevitable differences.
This pull request is:
- [x] A documentation / typographical / small typing error fix
- Good to go, no issue or tests are needed
**Have a nice day!**
Closes: #12078
Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/12078
Pull-request-sha: 7c4dcf9403
Change-Id: I3678976f5524ee164dc31b3122b224ae37060b71
### Description
Simplifies language use in [Getting a Connection](https://docs.sqlalchemy.org/en/20/tutorial/dbapi_transactions.html#getting-a-connection) and [Committing Changes](https://docs.sqlalchemy.org/en/20/tutorial/dbapi_transactions.html#committing-changes)
### Checklist
This pull request is:
- [x] A documentation / typographical / small typing error fix
- Good to go, no issue or tests are needed
- [ ] 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: #11542
Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/11542
Pull-request-sha: d706e69fb6
Change-Id: I7788f2a16a5127b3c9623f7b00f06f649b04e0fb
### Description
This is my first pull request to sqlalchemy. It changes the writing style of two paragraphs in the unified tutorial [here](https://docs.sqlalchemy.org/en/20/tutorial/dbapi_transactions.html#working-with-transactions-and-the-dbapi). My goals were to.
1. Make them easier to read
2. Not change the meaning of the text.
3. Get feedback on whether this type of contribution is considered useful for sqlalchemy.
If this is a useful type of contribution, it might be good to discuss some general guidelines for me to adhere to as I continue. For instance:
- Prefer using present simple tense
- Remove superfluous words where possible
- Keep the pull requests to one or two h2 sections at a time, to make the review easier
### Checklist
This pull request is:
- [x] A documentation / typographical / small typing error fix
- Good to go, no issue or tests are needed
- [ ] 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.
I'm curious to hear what you all think. **Have a nice day!**
Closes: #11541
Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/11541
Pull-request-sha: 3179690e6a
Change-Id: I9b47f6ce4fd00c44c4b0e19957acf250f5e46d2f
Added new core execution option
paramref:`_engine.Connection.execution_options.preserve_rowcount`
to unconditionally save the ``rowcount`` attribute from the cursor in the
class:`_engine.Result` returned from an execution, regardless of the
statement being executed.
When this option is provided the correct value is also set when
an INSERT makes use of the "insertmanyvalues" mode, that may use
more than one actualy cursor execution.
Fixes: #10974
Change-Id: Icecef6b7539be9f0a1a02b9539864f5f163dcfbc
this includes setup.cfg changes for asyncio and
3.8 min support. it doesnt have any code changes in support
of these adjusments.
Fixes: #10197Fixes: #10357
Change-Id: Ic4569c770d1b893a067a9a5dfe13a6e28aaf47fa
Comments by Mike <mike_mp@zzzcomputing.com>:
"Referred towards" is not correct English and can be replaced directly
with "referred to". However, this then introduces a dangling
preposition to sentences which I don't think is appropriate for this
style of writing. So instead, use phrases like "known as",
"references", "to which X refers".
To help me identify dangling prepositions I made use of ChatGPT,
here's the log of how that transpired:
https://chat.openai.com/share/60d42ff4-c1ac-4232-893a-415c2b6d7320
Co-authored-by: Mike Bayer <mike_mp@zzzcomputing.com>
Closes: #10210
Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/10210
Pull-request-sha: 5d30e79c14
Change-Id: Ib6a98e5be441f5b25d3929a2efb7d873bcfef98e
Repaired a major shortcoming which was identified in the
:ref:`engine_insertmanyvalues` performance optimization feature first
introduced in the 2.0 series. This was a continuation of the change in
2.0.9 which disabled the SQL Server version of the feature due to a
reliance in the ORM on apparent row ordering that is not guaranteed to take
place. The fix applies new logic to all "insertmanyvalues" operations,
which takes effect when a new parameter
:paramref:`_dml.Insert.returning.sort_by_parameter_order` on the
:meth:`_dml.Insert.returning` or :meth:`_dml.UpdateBase.return_defaults`
methods, that through a combination of alternate SQL forms, direct
correspondence of client side parameters, and in some cases downgrading to
running row-at-a-time, will apply sorting to each batch of returned rows
using correspondence to primary key or other unique values in each row
which can be correlated to the input data.
Performance impact is expected to be minimal as nearly all common primary
key scenarios are suitable for parameter-ordered batching to be
achieved for all backends other than SQLite, while "row-at-a-time"
mode operates with a bare minimum of Python overhead compared to the very
heavyweight approaches used in the 1.x series. For SQLite, there is no
difference in performance when "row-at-a-time" mode is used.
It's anticipated that with an efficient "row-at-a-time" INSERT with
RETURNING batching capability, the "insertmanyvalues" feature can be later
be more easily generalized to third party backends that include RETURNING
support but not necessarily easy ways to guarantee a correspondence
with parameter order.
Fixes: #9618
References: #9603
Change-Id: I1d79353f5f19638f752936ba1c35e4dc235a8b7c
a new user spent many days misled by this paragraph thinking
they were required to use reflection for an existing database.
Change-Id: I4c6757b931481db7a8d4202334382143e1491935
* Make sure we have blue borders for all sections
* rewrite "blue border" text, refer to textual means of determining
subject matter for a section; "blue borders" are not a primary
source of information
* Add some more intro text that was missing
Change-Id: I4d599e13d23bad8bb3c199a11afb53e3e9100c59
References: #9450
Missing a word on the page `Working with Database Metadata`.
First paragraph under section 'Setting up MetaData with Table objects'.
"...the database which we query from is know [as] a table."
Co-authored-by: markie tee <cassette.head@gmail.com>
### Description
<!-- Describe your changes in detail -->
Fixes#9168
This PR replaces common occurrences of [PEP 585](https://peps.python.org/pep-0585/) style type annotations with annotations compatible with older versions of Python.
I searched for instances of the following supported types from the PEP and replaced with their legacy typing couterparts.
* tuple # typing.Tuple
* list # typing.List
* dict # typing.Dict
* set # typing.Set
* frozenset # typing.FrozenSet
* type # typing.Type
```
grep -r "list\[.*\]" ./build --exclude-dir="./build/venv/*" --exclude-dir="./build/output/*" --exclude="changelog_[0-9]*\.rst"
```
I excluded changelog files from being altered, I think some of these could be changed if necessary but others are likely to require manual checking as the change may target the new typing style specifically.
For any examples that included imports, I tried to ensure that the correct typing imports were included and properly ordered.
### 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:
- [x] A documentation / typographical error fix
- Good to go, no issue or tests are needed
- [ ] 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.
Closes: #9198
Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/9198
Pull-request-sha: 05ad4651b5
Change-Id: I41b93b3dee85f9fe00cfbb3d3eb011212795de29
try to keep the wordiness down here, using sidebars
and topics for non-essential information. Sphinx seems
to read out attrs from under TYPE_CHECKING sections now
so link out the attrs in DeclarativeBase w/ docstrings,
not sure why we didn't think of this earlier. looks great
Change-Id: Ib2e07e3606185998561c2d77b2564fd3eddb4d75
updates for Insert / bulk insert, executemanyvalues,
as well as beginning to describe Table / declared class more
closely together, mentioning typing support.
Fixed a long-standing issue where sphinx would complain about
the Insert symbol being ambiguous.
Change-Id: Id4cc09b9581e8fa39c9c00bc8f229636e626e9bc
Fixed issue in Oracle compiler where the syntax for
:meth:`.FunctionElement.column_valued` was incorrect, rendering the name
``COLUMN_VALUE`` without qualifying the source table correctly.
Fixes: #8945
Change-Id: Ia04bbdc68168e78b67a74bb3834a63f5d5000627
biggest change here is the old tutorials were removed from the
TOC and some additional links to them have been corrected.
Change-Id: I79b878a946422eac24ed2449b440fc5d556576c4
* requirements needs typing_extensions
* update all "future=True" references to be appropriate to 2.0
Change-Id: I2eeb0ae65afdb587f21aeb0020f1d8a292f67c21
also fixes issue in format_docs_code which didn't work with
pre-commit for more than one file. will backport
Fixes: #8597
Change-Id: I21b2625514987b1cd90f7c00f06e72e57e257390
Greg Jarzab