summaryrefslogtreecommitdiff
path: root/lib/sqlalchemy/sql
Commit message (Collapse)AuthorAgeFilesLines
...
* Merge "translate joined inheritance cols in UPDATE/DELETE" into mainmike bayer2022-08-051-0/+1
|\
| * translate joined inheritance cols in UPDATE/DELETEMike Bayer2022-08-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed issue in ORM enabled UPDATE when the statement is created against a joined-inheritance subclass, updating only local table columns, where the "fetch" synchronization strategy would not render the correct RETURNING clause for databases that use RETURNING for fetch synchronization. Also adjusts the strategy used for RETURNING in UPDATE FROM and DELETE FROM statements. Also fixes MariaDB which does not support RETURNING with DELETE..USING. this was not caught in tests because "fetch" strategy wasn't tested. so also adjust the ORMDMLState classes to look for "extra froms" first before adding RETURNING, add new parameters to interfaces for "update_returning_multitable" and "delete_returning_multitable". A new execution option is_delete_using=True, described in the changelog message, is added to allow the ORM to know up front if a certain statement should have a SELECT up front for "fetch" strategy. Fixes: #8344 Change-Id: I3dcdb68e6e97ab0807a573c2fdb3d53c16d063ba
* | include column.default, column.onupdate in eager_defaultsMike Bayer2022-08-051-3/+19
|/ | | | | | | | | | | | | Fixed bug in the behavior of the :paramref:`_orm.Mapper.eager_defaults` parameter such that client-side SQL default or onupdate expressions in the table definition alone will trigger a fetch operation using RETURNING or SELECT when the ORM emits an INSERT or UPDATE for the row. Previously, only server side defaults established as part of table DDL and/or server-side onupdate expressions would trigger this fetch, even though client-side SQL expressions would be included when the fetch was rendered. Fixes: #7438 Change-Id: Iba719298ba4a26d185edec97ba77d2d54585e5a4
* update quoted_name docMike Bayer2022-08-041-1/+2
| | | | | Fixes: #8339 Change-Id: If78bc9babfdc6a4dde4e65d72858ac7a402cbb4d
* implement tuple-slices from .c collectionsMike Bayer2022-08-011-26/+60
| | | | | | | | | | | | 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
* Remove `__cmp__` methods (#8313)Nikita Sobolev2022-07-311-1/+1
|
* Update to flake8 5.Federico Caselli2022-07-314-15/+19
| | | | Change-Id: I5a241a70efba68bcea9819ddce6aebc25703e68d
* Remove all `__nonzero__` methods (#8308)Nikita Sobolev2022-07-302-6/+0
|
* Merge "feat: add `drop constraint if exists` to compiler" into mainmike bayer2022-07-281-2/+3
|\
| * feat: add `drop constraint if exists` to compilerMike Fiedler2022-07-031-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ### Description Add `DROP CONSTRAINT ... IF EXISTS` behavior to the compiler. Fixes https://github.com/sqlalchemy/sqlalchemy/issues/8141 ### 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 - [ ] 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. - [x] 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: #8161 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/8161 Pull-request-sha: 43276e29fa864fc66900c5a3fa0bf84df5f14271 Change-Id: I18bae3cf013159b6fffde4413fb59ce19ff83c16
* | Use FETCH FIRST N ROWS / OFFSET for Oracle LIMIT/OFFSETMike Bayer2022-07-201-10/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Oracle will now use FETCH FIRST N ROWS / OFFSET syntax for limit/offset support by default for Oracle 12c and above. This syntax was already available when :meth:`_sql.Select.fetch` were used directly, it's now implied for :meth:`_sql.Select.limit` and :meth:`_sql.Select.offset` as well. I'm currently setting this up so that the new syntax renders in Oracle using POSTCOMPILE binds. I really have no indication if Oracle's SQL optimizer would be better with params here, so that it can cache the SQL plan, or if it expects hardcoded numbers for these. Since we had reports that the previous ROWNUM thing really needed hardcoded ints, let's guess for now that hardcoded ints would be preferable. it can be turned off with a single boolean if users report that they'd prefer real bound values. Fixes: #8221 Change-Id: I812ec24ffc947199866947b666d6ec6e6a690f22
* | Merge "fixes for mypy 0.971" into mainmike bayer2022-07-192-8/+10
|\ \
| * | fixes for mypy 0.971Mike Bayer2022-07-192-8/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | things that were passing with 0.961 need adjustment. it seems mypy has become very pedantic about the difference between importing from a module vs. accessing members of that module as instance variables, so adjust the preloaded typing block to be explicitly instance variables, since that's how the accessor works in any case. Change-Id: I746a3c9102530b7cf9b123aec7be6376657c1169
* | | check for TypeDecorator when handling getitemMike Bayer2022-07-192-2/+27
|/ / | | | | | | | | | | | | | | | | Fixed issue where :class:`.TypeDecorator` would not correctly proxy the ``__getitem__()`` operator when decorating the :class:`.ARRAY` datatype, without explicit workarounds. Fixes: #7249 Change-Id: I3273572b4757e41fb5952639cb867314227d368a
* | use concat() directly for contains, startswith, endswithMike Bayer2022-07-172-7/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adjusted the SQL compilation for string containment functions ``.contains()``, ``.startswith()``, ``.endswith()`` to force the use of the string concatenation operator, rather than relying upon the overload of the addition operator, so that non-standard use of these operators with for example bytestrings still produces string concatenation operators. To accommodate this, needed to add a new _rconcat operator function, which is private, as well as a fallback in concat_op() that works similarly to Python builtin ops. Fixes: #8253 Change-Id: I2b7f56492f765742d88cb2a7834ded6a2892bd7e
* | implement column._merge()Mike Bayer2022-07-161-1/+112
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | this takes the user-defined args of one Column and merges them into the not-user-defined args of another Column. Implemented within the pep-593 column transfer operation to begin to make this new feature more robust. work may still be needed for constraints etc. but in theory everything from the left side annotated column should take effect for the right side if not otherwise specified on the right. Change-Id: I57eb37ed6ceb4b60979a35cfc4b63731d990911d
* | support "SELECT *" for ORM queriesMike Bayer2022-07-101-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A :func:`_sql.select` construct that is passed a sole '*' argument for ``SELECT *``, either via string, :func:`_sql.text`, or :func:`_sql.literal_column`, will be interpreted as a Core-level SQL statement rather than as an ORM level statement. This is so that the ``*``, when expanded to match any number of columns, will result in all columns returned in the result. the ORM- level interpretation of :func:`_sql.select` needs to know the names and types of all ORM columns up front which can't be achieved when ``'*'`` is used. If ``'*`` is used amongst other expressions simultaneously with an ORM statement, an error is raised as this can't be interpreted correctly by the ORM. Fixes: #8235 Change-Id: Ic8e84491e14acdc8570704eadeaeaf6e16b1e870
* | generalize sql server check for id col to accommodate ORM casesMike Bayer2022-07-063-4/+43
|/ | | | | | | | | | | | | | Fixed issues that prevented the new usage patterns for using DML with ORM objects presented at :ref:`orm_dml_returning_objects` from working correctly with the SQL Server pyodbc dialect. Here we add a step to look in compile_state._dict_values more thoroughly for the keys we need to determine "identity insert" or not, and also add a new compiler variable dml_compile_state so that we can skip the ORM's compile_state if present. Fixes: #8210 Change-Id: Idbd76bb3eb075c647dc6c1cb78f7315c821e15f7
* fix formatting problemsMike Bayer2022-07-031-4/+5
| | | | Change-Id: Ib55fe1c60130a45bfbf28de5c74cfe7a30418bb3
* call toinstance() on type arguments passed to mapped_column()Mike Bayer2022-07-022-3/+5
| | | | Change-Id: I875cfbd925cb08e0a5235f87d13341d319c955bc
* Merge "Change setinputsizes behavior for mssql+pyodbc" into mainmike bayer2022-06-291-1/+1
|\
| * Change setinputsizes behavior for mssql+pyodbcGord Thompson2022-06-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ``use_setinputsizes`` parameter for the ``mssql+pyodbc`` dialect now defaults to ``True``; this is so that non-unicode string comparisons are bound by pyodbc to pyodbc.SQL_VARCHAR rather than pyodbc.SQL_WVARCHAR, allowing indexes against VARCHAR columns to take effect. In order for the ``fast_executemany=True`` parameter to continue functioning, the ``use_setinputsizes`` mode now skips the ``cursor.setinputsizes()`` call specifically when ``fast_executemany`` is True and the specific method in use is ``cursor.executemany()``, which doesn't support setinputsizes. The change also adds appropriate pyodbc DBAPI typing to values that are typed as :class:`_types.Unicode` or :class:`_types.UnicodeText`, as well as altered the base :class:`_types.JSON` datatype to consider JSON string values as :class:`_types.Unicode` rather than :class:`_types.String`. Fixes: #8177 Change-Id: I6c8886663254ae55cf904ad256c906e8f5e11f48
* | Comments on (named) constraintscheremnov2022-06-293-0/+51
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adds support for comments on named constraints, including `ForeignKeyConstraint`, `PrimaryKeyConstraint`, `CheckConstraint`, `UniqueConstraint`, solving the [Issue 5667](https://github.com/sqlalchemy/sqlalchemy/issues/5667). Supports only PostgreSQL backend. ### Description Following the example of [Issue 1546](https://github.com/sqlalchemy/sqlalchemy/issues/1546), supports comments on constraints. Specifically, enables comments on _named_ ones — as I get it, PostgreSQL prohibits comments on unnamed constraints. Enables setting the comments for named constraints like this: ``` Table( 'example', metadata, Column('id', Integer), Column('data', sa.String(30)), PrimaryKeyConstraint( "id", name="id_pk", comment="id_pk comment" ), CheckConstraint('id < 100', name="cc1", comment="Id value can't exceed 100"), UniqueConstraint(['data'], name="uc1", comment="Must have unique data field"), ) ``` Provides the DDL representation for constraint comments and routines to create and drop them. Class `.Inspector` reflects constraint comments via methods like `get_check_constraints` . ### 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 - [ ] A short code fix - [x] A new feature implementation - Solves the issue 5667. - The commit message includes `Fixes: 5667`. - Includes tests based on comment reflection. **Have a nice day!** Fixes: #5667 Closes: #7742 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/7742 Pull-request-sha: 42a5d3c3e9ccf9a9d5397fd007aeab0854f66130 Change-Id: Ia60f578595afdbd6089541c9a00e37997ef78ad3
* merge column args from Annotated left sideMike Bayer2022-06-281-1/+0
| | | | | | | | | | | | because we are forced by pep-681 to use the argument "default", we need a way to have client Column default separate from a dataclasses level default. Also, pep-681 does not support deriving the descriptor function from Annotated, so allow a brief right side mapped_column() to be present that will have more column-centric arguments from the left side Annotated to be merged. Change-Id: I039be1628d498486ba013b2798e1392ed1cd7f9f
* require at least one dialect name for variantMike Bayer2022-06-261-5/+6
| | | | | | | the call doesn't make sense otherwise Fixes: #8179 Change-Id: I0e5dd584dc7090b536f9732cbfc6f3a5c8846dc5
* Domain typeDavid Baumgold2022-06-211-8/+9
| | | | | | | | | | | | | | Added a new Postgresql :class:`_postgresql.DOMAIN` datatype, which follows the same CREATE TYPE / DROP TYPE behaviors as that of PostgreSQL :class:`_postgresql.ENUM`. Much thanks to David Baumgold for the efforts on this. Fixes: #7316 Closes: #7317 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/7317 Pull-request-sha: bc9a82f010e6ca2f70a6e8a7620b748e483c26c3 Change-Id: Id8d7e48843a896de17d20cc466b115b3cc065132
* Merge "rearchitect reflection for batched performance" into mainFederico Caselli2022-06-183-9/+73
|\
| * rearchitect reflection for batched performanceFederico Caselli2022-06-183-9/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rearchitected the schema reflection API to allow some dialects to make use of high performing batch queries to reflect the schemas of many tables at once using much fewer queries. The new performance features are targeted first at the PostgreSQL and Oracle backends, and may be applied to any dialect that makes use of SELECT queries against system catalog tables to reflect tables (currently this omits the MySQL and SQLite dialects which instead make use of parsing the "CREATE TABLE" statement, however these dialects do not have a pre-existing performance issue with reflection. MS SQL Server is still a TODO). The new API is backwards compatible with the previous system, and should require no changes to third party dialects to retain compatibility; third party dialects can also opt into the new system by implementing batched queries for schema reflection. Along with this change is an updated reflection API that is fully :pep:`484` typed, features many new methods and some changes. Fixes: #4379 Change-Id: I897ec09843543aa7012bcdce758792ed3d415d08
* | Merge "Normalize postgresql docs links to point to current" into mainmike bayer2022-06-182-10/+10
|\ \
| * | Normalize postgresql docs links to point to currentFederico Caselli2022-06-172-10/+10
| | | | | | | | | | | | Change-Id: Ib7d3ea7ff3356ff8a2f935892d904a69dbc25c3e
* | | Merge "Allow NUMERIC()/DECIMAL() IDENTITY columns" into mainmike bayer2022-06-183-1/+14
|\ \ \ | |/ / |/| |
| * | Allow NUMERIC()/DECIMAL() IDENTITY columnsGord Thompson2022-06-183-1/+14
| |/ | | | | | | | | | | | | | | | | | | | | | | Fixed issue where :class:`.Table` objects that made use of IDENTITY columns with a :class:`.Numeric` datatype would produce errors when attempting to reconcile the "autoincrement" column, preventing construction of the :class:`.Column` from using the :paramref:`.Column.autoincrement` parameter as well as emitting errors when attempting to invoke an :class:`.Insert` construct. Fixes: #8111 Change-Id: Iaacc4eebfbafb42fa18f9a1a4f43cb2b6b91d28a
* | implement literal stringification for arraysMike Bayer2022-06-151-0/+58
|/ | | | | | | | | | | | | | | as we already implement stringification for the contents, provide a bracketed syntax for default and ARRAY literal for PG specifically. ARRAY literal seems much simpler to render than their quoted syntax which requires double quotes for strings. also open up testing for pg8000 which has likely been fine with arrays for awhile now, bump the version pin also. Fixes: #8138 Change-Id: Id85b052b0a9564d6aa1489160e58b7359f130fdd
* new features for pep 593 AnnotatedMike Bayer2022-06-151-0/+4
| | | | | | | | | | | | | | | * extract the inner type from Annotated when the outer type isn't present in the type map, to allow for arbitrary Annotated * allow _IntrospectsAnnotations objects to be directly present in an Annotated and resolve the mapper property from that. Currently implemented for mapped_column(), with message for others. Can work for composite() and likely some relationship() as well at some point References: https://twitter.com/zzzeek/status/1536693554621341697 and replies Change-Id: I04657050a8785f194bf8f63291faf3475af88781
* typing adjustments for compositesMike Bayer2022-06-141-1/+1
| | | | | | | | | * if dataclass isn't used, columns have to be named * _CompositeClassProto is not useful as dataclasses have no methods / bases we can use, so composite is against Any * Adjust session.get() feature to work w/ dataclass composites Change-Id: Icc606cc76871c738dc794ea4555fca8a1ab0e0fd
* Merge "honor enum length in all cases" into mainmike bayer2022-06-101-19/+14
|\
| * honor enum length in all casesMike Bayer2022-06-101-19/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | The :paramref:`.Enum.length` parameter, which sets the length of the ``VARCHAR`` column for non-native enumeration types, is now used unconditionally when emitting DDL for the ``VARCHAR`` datatype, including when the :paramref:`.Enum.native_enum` parameter is set to ``True`` for target backends that continue to use ``VARCHAR``. Previously the parameter would be erroneously ignored in this case. The warning previously emitted for this case is now removed. Fixes: #7791 Change-Id: I91764546b56e9416479949be8a118cdc91ac5ed9
* | resolve large ints to BigIntegerMike Bayer2022-06-101-0/+7
|/ | | | | | | | | | | | The in-place type detection for Python integers, as occurs with an expression such as ``literal(25)``, will now apply value-based adaption as well to accommodate Python large integers, where the datatype determined will be :class:`.BigInteger` rather than :class:`.Integer`. This accommodates for dialects such as that of asyncpg which both sends implicit typing information to the driver as well as is sensitive to numeric scale. Fixes: #7909 Change-Id: I1cd3ec2676c9bb03ffedb600695252bd0037ba02
* Merge "restore parameter escaping for public methods" into mainmike bayer2022-06-091-7/+24
|\
| * restore parameter escaping for public methodsMike Bayer2022-06-091-7/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Adjusted the fix made for :ticket:`8056` which adjusted the escaping of bound parameter names with special characters such that the escaped names were translated after the SQL compilation step, which broke a published recipe on the FAQ illustrating how to merge parameter names into the string output of a compiled SQL string. The change restores the escaped names that come from ``compiled.params`` and adds a conditional parameter to :meth:`.SQLCompiler.construct_params` named ``escape_names`` that defaults to ``True``, restoring the old behavior by default. Fixes: #8113 Change-Id: I9cbedb1080bc06d51f287fd2cbf26aaab1c74653
* | Merge "fix race conditions in lambda statements" into mainmike bayer2022-06-093-7/+23
|\ \ | |/ |/|
| * fix race conditions in lambda statementsMike Bayer2022-06-083-7/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed multiple observed race conditions related to :func:`.lambda_stmt`, including an initial "dogpile" issue when a new Python code object is initially analyzed among multiple simultaneous threads which created both a performance issue as well as some internal corruption of state. Additionally repaired observed race condition which could occur when "cloning" an expression construct that is also in the process of being compiled or otherwise accessed in a different thread due to memoized attributes altering the ``__dict__`` while iterated, for Python versions prior to 3.10; in particular the lambda SQL construct is sensitive to this as it holds onto a single statement object persistently. The iteration has been refined to use ``dict.copy()`` with or without an additional iteration instead. Fixes: #8098 Change-Id: I4e0b627bfa187f1780dc68ec81b94db1c78f846a
* | Merge "graceful degrade for FKs not reflectable" into mainmike bayer2022-06-082-4/+39
|\ \
| * | graceful degrade for FKs not reflectableMike Bayer2022-06-072-4/+39
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Merge "migrate labels to new tutorial" into mainmike bayer2022-06-077-69/+30
|\ \ | |/ |/|
| * migrate labels to new tutorialMike Bayer2022-06-077-69/+30
| | | | | | | | | | | | | | other org changes and some sections from old tutorial ported to new tutorial. Change-Id: Ic0fba60ec82fff481890887beef9ed0fa271875a
* | Merge "Generalize RETURNING and suppor for MariaDB / SQLite" into mainmike bayer2022-06-055-25/+103
|\ \
| * | Generalize RETURNING and suppor for MariaDB / SQLiteDaniel Black2022-06-025-25/+103
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | | Docs Update - Add **kwargs to CaseInsensitiveComparator docs (#8063)Justin Crown2022-06-041-2/+2
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | * 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>
* | Merge "propagate proxy_key from WrapsColumnExpression" into mainmike bayer2022-06-011-0/+8
|\ \ | |/ |/|
View Lorry Controller Status