The :meth:`_sql.Select.filter_by`, :meth:`_sql.Update.filter_by` and
:meth:`_sql.Delete.filter_by` methods now search across all entities
present in the statement, rather than limiting their search to only the
last joined entity or the first FROM entity. This allows these methods
to locate attributes unambiguously across multiple joined tables,
resolving issues where changing the order of operations such as
:meth:`_sql.Select.with_only_columns` would cause the method to fail.
If an attribute name exists in more than one FROM clause entity, an
:class:`_exc.AmbiguousColumnError` is now raised, indicating that
:meth:`_sql.Select.filter` (or :meth:`_sql.Select.where`) should be used
instead with explicit table-qualified column references.
Fixes: #8601
Change-Id: I6a46b8f4784801f95f7980ca8ef92f1947653572
Added support for the SQL ``CREATE VIEW`` statement via the new
:class:`.CreateView` DDL class. The new class allows creating database
views from SELECT statements, with support for options such as
``TEMPORARY``, ``IF NOT EXISTS``, and ``MATERIALIZED`` where supported by
the target database. Views defined with :class:`.CreateView` integrate with
:class:`.MetaData` for automated DDL generation and provide a
:class:`.Table` object for querying.
this alters the CreateTableAs commit:
* adds the ability for Table to be associated with Create and Drop
DDL constructs
* Adds CreateView variant of CreateTableAs
* Both associate themselves with Table so they take place in
create_all/create/drop_all/drop
Fixes: #181
Change-Id: If3e568d3d6a6ce19e3d15198c3fbbe06bd847c83
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
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
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
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.
Change-Id: Ib28270d8da8616b533953204e22eabee9388d620
Added script to format code in the rst documentation using black.
This is also added to the lint tox job to ensure that the code
in the docs is properly formatted.
Change-Id: I799444f22da153484ca5f095d57755762348da40
Added new syntax to the ``.c`` collection on all :class:`.FromClause`
objects allowing tuples of keys to be passed to ``__getitem__()``, along
with support for ``select()`` handling of ``.c`` collections directly,
allowing the syntax ``select(table.c['a', 'b', 'c'])`` to be possible. The
sub-collection returned is itself a :class:`.ColumnCollection` which is
also directly consumable by :func:`_sql.select` and similar now.
Fixes: #8285
Change-Id: I2236662c477ffc50af079310589e213323c960d1
this is the tutorial, which should have some semblence of
not getting too far into the weeds. however, as we dont
really have other places to explain SQL concepts, and SQL
functions have a lot of them, we dont have another home right
now. so at least further sub-categorize window functions,
table/column valued functions, and WITHIN GROUP into an
"advanced function techniques" section with a disclaimer that
these are less common use cases.
Change-Id: I4b16bd5673c0bd39a9b880338f6ce3cfbafbe271
This is done in 1.4 style so it can be backported to 1.4.
Will put this up as is, we can work on it. For 2.0, the
ORM mapping will be updated to mapped_column() style when
we do the full pass.
Change-Id: Icfdf81449973844dac244b3a107ce955a7d3b16c
(redo of 2999/I5609025feee8cfdecc09b55bfbf1bd13fa2e6602)
This PR is designed to bring more clarity within the docs by renaming object
instances that may be consfusingly similar to class, method, and attribute names.
For example, instances of the class `MetaData` are available on some objects as
`.metadata` property, and had appeared within the docs as both `meta` and
`metadata` which has confused some users in the past. By this PR, the docs now
utilize the following naming convention:
* MetaData - SQLAlchemy class
* .metadata - SQLAlchemy API attributes
* metadata_obj - developer instantiated metadata objects or references
Detailed Changes:
* standardized `meta` and `metadata` instances to `metadata_obj`. note: the docs were evenly split between 'meta' and 'metadata'.
* standardized 'cursor' to 'cursor_obj' to avoid confusion with the method.
* standardized a 'scalar_subquery = ' to 'scalar_subq' to avoid confusion with the method.
* standardized a 'cte = ' to 'cte_obj' to avoid confusion with the method
Change-Id: I79c98aee16c5fc6649289b2dd7d6dfc368222fb4
the query in the second union example needs order by to
produce determinstic results on all plaforms including
OSX, arm
Change-Id: I88fcc391561db8567c389ed9e904e5de29c1c2ad
This breaks data.rst into three separate sub-sections,
as SELECT is getting very long. It then adds sections
on select() + text/literal_column as well as unions
and set operations, and also tries to improve the
ORDER BY section a bit.
Change-Id: Id90e6b4ff3699b2bbcb6e2eebbd23193e2ede00a
Mike Bayer