summaryrefslogtreecommitdiff
path: root/test/sql/test_query.py
Commit message (Collapse)AuthorAgeFilesLines
* upgrade to black 20.8b1Mike Bayer2020-09-281-9/+23
| | | | | | | It's better, the majority of these changes look more readable to me. also found some docstrings that had formatting / quoting issues. Change-Id: I582a45fde3a5648b2f36bab96bad56881321899b
* Update select usage to use the new 1.4 formatFederico Caselli2020-09-081-237/+212
| | | | | | | | | | | | | | | | This change includes mainly that the bracketed use within select() is moved to positional, and keyword arguments are removed from calls to the select() function. it does not yet fully address other issues such as keyword arguments passed to the table.select(). Additionally, allows False / None to both be considered as "disable" for all of select.correlate(), select.correlate_except(), query.correlate(), which establishes consistency with passing of ``False`` for the legact select(correlate=False) argument. Change-Id: Ie6c6e6abfbd3d75d4c8de504c0cf0159e6999108
* Create a real type for Tuple() and handle appropriately in compilerMike Bayer2020-08-171-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | Improved the :func:`_sql.tuple_` construct such that it behaves predictably when used in a columns-clause context. The SQL tuple is not supported as a "SELECT" columns clause element on most backends; on those that do (PostgreSQL, not surprisingly), the Python DBAPI does not have a "nested type" concept so there are still challenges in fetching rows for such an object. Use of :func:`_sql.tuple_` in a :func:`_sql.select` or :class:`_orm.Query` will now raise a :class:`_exc.CompileError` at the point at which the :func:`_sql.tuple_` object is seen as presenting itself for fetching rows (i.e., if the tuple is in the columns clause of a subquery, no error is raised). For ORM use,the :class:`_orm.Bundle` object is an explicit directive that a series of columns should be returned as a sub-tuple per row and is suggested by the error message. Additionally ,the tuple will now render with parenthesis in all contexts. Previously, the parenthesization would not render in a columns context leading to non-defined behavior. As part of this change, Tuple receives a dedicated datatype which appears to allow us the very desirable change of removing the bindparam._expanding_in_types attribute as well as ClauseList._tuple_values (which might already have not been needed due to #4645). Fixes: #5127 Change-Id: Iecafa0e0aac2f1f37ec8d0e1631d562611c90200
* Clean up .execute in test/sql/test_query.pyGord Thompson2020-04-121-397/+413
| | | | Change-Id: I3f3a3b3f7a7ec67ef475a9792372e1c9a600fafb
* Result initial introductionMike Bayer2020-02-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This builds on cc718cccc0bf8a01abdf4068c7ea4f3 which moved RowProxy to Row, allowing Row to be more like a named tuple. - KeyedTuple in ORM is replaced with Row - ResultSetMetaData broken out into "simple" and "cursor" versions for ORM and Core, as well as LegacyCursor version. - Row now has _mapping attribute that supplies full mapping behavior. Row and SimpleRow both have named tuple behavior otherwise. LegacyRow has some mapping features on the tuple which emit deprecation warnings (e.g. keys(), values(), etc). the biggest change for mapping->tuple is the behavior of __contains__ which moves from testing of "key in row" to "value in row". - ResultProxy breaks into ResultProxy and FutureResult (interim), the latter has the newer APIs. Made available to dialects using execution options. - internal reflection methods and most tests move off of implicit Row mapping behavior and move to row._mapping, result.mappings() method using future result - a new strategy system for cursor handling replaces the various subclasses of RowProxy - some execution context adjustments. We will leave EC in but refined things like get_result_proxy() and out parameter handling. Dialects for 1.4 will need to adjust from get_result_proxy() to get_result_cursor_strategy(), if they are using this method - out parameter handling now accommodated by get_out_parameter_values() EC method. Oracle changes for this. external dialect for DB2 for example will also need to adjust for this. - deprecate case_insensitive flag for engine / result, this feature is not used mapping-methods on Row are deprecated, and replaced with Row._mapping.<meth>, including: row.keys() -> use row._mapping.keys() row.items() -> use row._mapping.items() row.values() -> use row._mapping.values() key in row -> use key in row._mapping int in row -> use int < len(row) Fixes: #4710 Fixes: #4878 Change-Id: Ieb9085e9bcff564359095b754da9ae0af55679f0
* Update test reqs for mariadb 10.4, 10.5Mike Bayer2020-02-161-3/+7
| | | | | | | A few except / union tests seem to be passing on these two versions which are now up on CI. Change-Id: I0d65795357a6d03962d7182dda198d890a4c3f97
* MSSQL 2014 OFFSET/FETCH syntax supportElkin2020-02-071-1/+0
| | | | | | | | | | | | | | SQL Server OFFSET and FETCH keywords are now used for limit/offset, rather than using a window function, for SQL Server versions 11 and higher. TOP is still used for a query that features only LIMIT. Pull request courtesy Elkin. Fixes: #5084 Closes: #5125 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/5125 Pull-request-sha: a45b7f73090d2053e3a7020d4e3d7fabb0c5627d Change-Id: Id6a01ba30caac87d7d3d92c3903cdfd77fbcee5e
* Use expanding IN for all literal value IN expressionsMike Bayer2019-12-221-36/+1
| | | | | | | | | | | | | | | | | | | | | | | | The "expanding IN" feature, which generates IN expressions at query execution time which are based on the particular parameters associated with the statement execution, is now used for all IN expressions made against lists of literal values. This allows IN expressions to be fully cacheable independently of the list of values being passed, and also includes support for empty lists. For any scenario where the IN expression contains non-literal SQL expressions, the old behavior of pre-rendering for each position in the IN is maintained. The change also completes support for expanding IN with tuples, where previously type-specific bind processors weren't taking effect. As part of this change, a more explicit separation between "literal execute" and "post compile" bound parameters is being made; as the "ansi bind rules" feature is rendering bound parameters inline, as we now support "postcompile" generically, these should be used here, however we have to render literal values at execution time even for "expanding" parameters. new test fixtures etc. are added to assert everything goes to the right place. Fixes: #4645 Change-Id: Iaa2b7bfbfaaf5b80799ee17c9b8507293cba6ed1
* Copy bind_processors when altering for expanding INMike Bayer2019-12-201-0/+46
| | | | | | | | | | | | | | | | Fixed issue where the collection of value processors on a :class:`.Compiled` object would be mutated when "expanding IN" parameters were used with a datatype that has bind value processors; in particular, this would mean that when using statement caching and/or baked queries, the same compiled._bind_processors collection would be mutated concurrently. Since these processors are the same function for a given bind parameter namespace every time, there was no actual negative effect of this issue, however, the execution of a :class:`.Compiled` object should never be causing any changes in its state, especially given that they are intended to be thread-safe and reusable once fully constructed. Fixes: #5048 Change-Id: I876d16bd7484eb05ce590397420552ac36da6e52
* SelectBase no longer a FromClauseMike Bayer2019-07-061-1/+1
| | | | | | | | | | | | | | | | | | | | As part of the SQLAlchemy 2.0 migration project, a conceptual change has been made to the role of the :class:`.SelectBase` class hierarchy, which is the root of all "SELECT" statement constructs, in that they no longer serve directly as FROM clauses, that is, they no longer subclass :class:`.FromClause`. For end users, the change mostly means that any placement of a :func:`.select` construct in the FROM clause of another :func:`.select` requires first that it be wrapped in a subquery first, which historically is through the use of the :meth:`.SelectBase.alias` method, and is now also available through the use of :meth:`.SelectBase.subquery`. This was usually a requirement in any case since several databases don't accept unnamed SELECT subqueries in their FROM clause in any case. See the documentation in this change for lots more detail. Fixes: #4617 Change-Id: I0f6174ee24b9a1a4529168e52e855e12abd60667
* Post black reformattingMike Bayer2019-01-061-38/+34
| | | | | | | | | | | | | Applied on top of a pure run of black -l 79 in I7eda77fed3d8e73df84b3651fd6cfcfe858d4dc9, this set of changes resolves all remaining flake8 conditions for those codes we have enabled in setup.cfg. Included are resolutions for all remaining flake8 issues including shadowed builtins, long lines, import order, unused imports, duplicate imports, and docstring issues. Change-Id: I4f72d3ba1380dd601610ff80b8fb06a2aff8b0fe
* Run black -l 79 against all source filesMike Bayer2019-01-061-554/+930
| | | | | | | | | | | | | | This is a straight reformat run using black as is, with no edits applied at all. The black run will format code consistently, however in some cases that are prevalent in SQLAlchemy code it produces too-long lines. The too-long lines will be resolved in the following commit that will resolve all remaining flake8 issues including shadowed builtins, long lines, import order, unused imports, duplicate imports, and docstring issues. Change-Id: I7eda77fed3d8e73df84b3651fd6cfcfe858d4dc9
* Maintain compiled_params / replacement_expressions within expanding INMike Bayer2018-12-211-0/+35
| | | | | | | | | Fixed issue in "expanding IN" feature where using the same bound parameter name more than once in a query would lead to a KeyError within the process of rewriting the parameters in the query. Fixes: #4394 Change-Id: Ibcadce9fefbcb060266d9447c2044ee6efeccf5a
* MariaDB 10.3 updatesMike Bayer2018-08-301-2/+4
| | | | | | | | | MariaDB seems to handle some additional UPDATE/DELETE FROM syntaxes as well as some forms of INTERSECT and EXCEPT. Open up tests that expect failure for MySQL to allow success for MariaDB 10.3. Change-Id: Ia9341a82485ef7201bb8130d8dbf4a9b6976035a
* Add support of empty list in exanding of bindparamNicolas Rolin2018-08-071-5/+3
| | | | | | | | | | | Added new logic to the "expanding IN" bound parameter feature whereby if the given list is empty, a special "empty set" expression that is specific to different backends is generated, thus allowing IN expressions to be fully dynamic including empty IN expressions. Fixes: #4271 Change-Id: Icc3c73bbd6005206b9d06baaeb14a097af5edd36 Pull-request: https://github.com/zzzeek/sqlalchemy/pull/432
* Fix regexp for expanding INMike Bayer2017-12-011-0/+60
| | | | | | | | | Fixed bug in new "expanding bind parameter" feature whereby if multiple params were used in one statement, the regular expression would not match the parameter name correctly. Change-Id: Ifaf7d627aac4ead2a13c8dddccb5c515253d88e6 Fixes: #4140
* Add SQL Server CI coverageMike Bayer2017-08-311-3/+1
| | | | Change-Id: Ida0d01ae9bcc0573b86e24fddea620a38c962822
* Add new "expanding" feature to bindparam()Mike Bayer2017-04-071-2/+72
| | | | | | | | | | | | | | | | Added a new kind of :func:`.bindparam` called "expanding". This is for use in ``IN`` expressions where the list of elements is rendered into individual bound parameters at statement execution time, rather than at statement compilation time. This allows both a single bound parameter name to be linked to an IN expression of multiple elements, as well as allows query caching to be used with IN expressions. The new feature allows the related features of "select in" loading and "polymorphic in" loading to make use of the baked query extension to reduce call overhead. This feature should be considered to be **experimental** for 1.2. Fixes: #3953 Change-Id: Ie708414a3ab9c0af29998a2c7f239ff7633b1f6e
* Add "empty in" strategies; default to "static"Mike Bayer2017-03-141-18/+54
| | | | | | | | | | | | | | | The longstanding behavior of the :meth:`.Operators.in_` and :meth:`.Operators.not_in_` operators emitting a warning when the right-hand condition is an empty sequence has been revised; a new flag :paramref:`.create_engine.empty_in_strategy` allows an empty "IN" expression to generate a simple boolean expression, or to invoke the previous behavior of dis-equating the expression to itself, with or without a warning. The default behavior is now to emit the simple boolean expression, allowing an empty IN to be evaulated without any performance penalty. Change-Id: I65cc37f2d7cf65a59bf217136c42fee446929352 Fixes: #3907
* Make all tests to be PEP8 compliantKhairi Hafsham2017-02-071-2/+5
| | | | | | | | tested using pycodestyle version 2.2.0 Fixes: #3885 Change-Id: I5df43adc3aefe318f9eeab72a078247a548ec566 Pull-request: https://github.com/zzzeek/sqlalchemy/pull/343
* Support python3.6Mike Bayer2017-01-131-1/+1
| | | | | | | | | | | Corrects some warnings and adds tox config. Adds DeprecationWarning to the error category. Large sweep for string literals w/ backslashes as this is common in docstrings Co-authored-by: Andrii Soldatenko Fixes: #3886 Change-Id: Ia7c838dfbbe70b262622ed0803d581edc736e085 Pull-request: https://github.com/zzzeek/sqlalchemy/pull/337
* - break out critical aspects of test_query into their own testsMike Bayer2015-09-271-1416/+4
| | | | | finally, test_resultset and test_insert_exec. Update all idioms within these.
* - Fixed regression where new methods on :class:`.ResultProxy` usedMike Bayer2015-07-191-2/+10
| | | | | | | | | by the ORM :class:`.Query` object (part of the performance enhancements of :ticket:`3175`) would not raise the "this result does not return rows" exception in the case where the driver (typically MySQL) fails to generate cursor.description correctly; an AttributeError against NoneType would be raised instead. fixes #3481
* - pg8000 very annoyingly complaining here, use total literalMike Bayer2015-07-191-1/+2
|
* - Fixed regression where :meth:`.ResultProxy.keys` would returnMike Bayer2015-07-191-5/+94
| | | | | | | | un-adjusted internal symbol names for "anonymous" labels, which are the "foo_1" types of labels we see generated for SQL functions without labels and similar. This was a side effect of the performance enhancements implemented as part of references #918. fixes #3483
* - ensure that the keys we put into the parameters dictionaryMike Bayer2015-04-081-1/+8
| | | | | | | for an insert from select are the string names, and not the Column objects. The MSSQL dialect in particular relies upon checking for these keys in params to know if identity insert should be on. references #3360
* - The "auto close" for :class:`.ResultProxy` is now a "soft" close.Mike Bayer2015-03-171-0/+3
| | | | | | | | | | | That is, after exhausing all rows using the fetch methods, the DBAPI cursor is released as before and the object may be safely discarded, but the fetch methods may continue to be called for which they will return an end-of-result object (None for fetchone, empty list for fetchmany and fetchall). Only if :meth:`.ResultProxy.close` is called explicitly will these methods raise the "result is closed" error. fixes #3330 fixes #3329
* - The SQL compiler now generates the mapping of expected columnspositional_targetingMike Bayer2015-03-071-0/+42
| | | | | | | | | | | | | | | | | such that they are matched to the received result set positionally, rather than by name. Originally, this was seen as a way to handle cases where we had columns returned with difficult-to-predict names, though in modern use that issue has been overcome by anonymous labeling. In this version, the approach basically reduces function call count per-result by a few dozen calls, or more for larger sets of result columns. The approach still degrades into a modern version of the old approach if textual elements modify the result map, or if any discrepancy in size exists between the compiled set of columns versus what was received, so there's no issue for partially or fully textual compilation scenarios where these lists might not line up. fixes #918 - callcounts still need to be adjusted down for this so zoomark tests won't pass at the moment
* - Exception messages have been spiffed up a bit. The SQL statementMike Bayer2014-10-171-4/+3
| | | | | | | | | | | and parameters are not displayed if None, reducing confusion for error messages that weren't related to a statement. The full module and classname for the DBAPI-level exception is displayed, making it clear that this is a wrapped DBAPI exception. The statement and parameters themselves are bounded within a bracketed sections to better isolate them from the error message and from each other. fixes #3172
* - additional issues fixed in mysqlconnector 2.0.1Mike Bayer2014-10-131-15/+0
|
* - Mysqlconnector as of version 2.0, probably as a side effect ofMike Bayer2014-10-121-6/+0
| | | | | | | | | | | | | | | | the python 3 merge, now does not expect percent signs (e.g. as used as the modulus operator and others) to be doubled, even when using the "pyformat" bound parameter format (this change is not documented by Mysqlconnector). The dialect now checks for py2k and for mysqlconnector less than version 2.0 when detecting if the modulus operator should be rendered as ``%%`` or ``%``. - Unicode SQL is now passed for MySQLconnector version 2.0 and above; for Py2k and MySQL < 2.0, strings are encoded. Note that mysqlconnector as of 2.0.1 appears to have a bug with unicode DDL on py2k, so the tests here are skipping until we observe it's fixed. - take out profiling on mysqlconnector, callcounts vary too much with its current development speed
* - The :func:`~.expression.column` and :func:`~.expression.table`Mike Bayer2014-09-011-4/+6
| | | | | | | | | | | | | | | | | | | | | constructs are now importable from the "from sqlalchemy" namespace, just like every other Core construct. - The implicit conversion of strings to :func:`.text` constructs when passed to most builder methods of :func:`.select` as well as :class:`.Query` now emits a warning with just the plain string sent. The textual conversion still proceeds normally, however. The only method that accepts a string without a warning are the "label reference" methods like order_by(), group_by(); these functions will now at compile time attempt to resolve a single string argument to a column or label expression present in the selectable; if none is located, the expression still renders, but you get the warning again. The rationale here is that the implicit conversion from string to text is more unexpected than not these days, and it is better that the user send more direction to the Core / ORM when passing a raw string as to what direction should be taken. Core/ORM tutorials have been updated to go more in depth as to how text is handled. fixes #2992
* - The INSERT...FROM SELECT construct now implies ``inline=True``Mike Bayer2014-08-201-0/+7
| | | | | | | | | | | | | | | | | | | | | | | on :class:`.Insert`. This helps to fix a bug where an INSERT...FROM SELECT construct would inadvertently be compiled as "implicit returning" on supporting backends, which would cause breakage in the case of an INSERT that inserts zero rows (as implicit returning expects a row), as well as arbitrary return data in the case of an INSERT that inserts multiple rows (e.g. only the first row of many). A similar change is also applied to an INSERT..VALUES with multiple parameter sets; implicit RETURNING will no longer emit for this statement either. As both of these constructs deal with varible numbers of rows, the :attr:`.ResultProxy.inserted_primary_key` accessor does not apply. Previously, there was a documentation note that one may prefer ``inline=True`` with INSERT..FROM SELECT as some databases don't support returning and therefore can't do "implicit" returning, but there's no reason an INSERT...FROM SELECT needs implicit returning in any case. Regular explicit :meth:`.Insert.returning` should be used to return variable numbers of result rows if inserted data is needed. fixes #3169
* - find the remaining not cleaning up correctly testMike Bayer2014-07-281-1/+2
|
* - scale up for mysql, sqliteMike Bayer2014-07-261-3/+3
|
* - update the flake8 rules againMike Bayer2014-07-181-2/+7
| | | | - apply autopep8 + manual fixes to most of test/sql/
* PEP8 tidy of subset of test/sql/*.pypr/103Tony Locke2014-07-071-436/+513
|
* pg8000 passing test/sqlTony Locke2014-07-061-2/+2
|
* mark failing tests for buggy mysqlconnectorMike Bayer2014-03-281-0/+21
|
* - rename __multiple__ to __backend__, and apply __backend__ to a large ↵Mike Bayer2014-03-241-0/+10
| | | | | | number of tests. - move out logging tests from test_execute to test_logging
* - add more support for suite tests, moving some tests from test_query out to ↵Mike Bayer2014-03-131-153/+24
| | | | | | suite and adding some more requirements
* - Support has been added for pytest to run tests. This runnerMike Bayer2014-03-031-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | is currently being supported in addition to nose, and will likely be preferred to nose going forward. The nose plugin system used by SQLAlchemy has been split out so that it works under pytest as well. There are no plans to drop support for nose at the moment and we hope that the test suite itself can continue to remain as agnostic of testing platform as possible. See the file README.unittests.rst for updated information on running tests with pytest. The test plugin system has also been enhanced to support running tests against mutiple database URLs at once, by specifying the ``--db`` and/or ``--dburi`` flags multiple times. This does not run the entire test suite for each database, but instead allows test cases that are specific to certain backends make use of that backend as the test is run. When using pytest as the test runner, the system will also run specific test suites multiple times, once for each database, particularly those tests within the "dialect suite". The plan is that the enhanced system will also be used by Alembic, and allow Alembic to run migration operation tests against multiple backends in one run, including third-party backends not included within Alembic itself. Third party dialects and extensions are also encouraged to standardize on SQLAlchemy's test suite as a basis; see the file README.dialects.rst for background on building out from SQLAlchemy's test platform.
* - More issues with [ticket:2932] first resolved in 0.9.2 whereMike Bayer2014-02-051-0/+30
| | | | | | | | | | using a column key of the form ``<tablename>_<columnname>`` matching that of an aliased column in the text would still not match at the ORM level, which is ultimately due to a core column-matching issue. Additional rules have been added so that the column ``_label`` is taken into account when working with a :class:`.TextAsFrom` construct or with literal columns. [ticket:2932]
* - Fixed bug in new :class:`.TextAsFrom` construct where :class:`.Column`-Mike Bayer2014-02-021-0/+45
| | | | | | | | | | oriented row lookups were not matching up to the ad-hoc :class:`.ColumnClause` objects that :class:`.TextAsFrom` generates, thereby making it not usable as a target in :meth:`.Query.from_statement`. Also fixed :meth:`.Query.from_statement` mechanics to not mistake a :class:`.TextAsFrom` for a :class:`.Select` construct. This bug is also an 0.9 regression as the :meth:`.Text.columns` method is called to accommodate the :paramref:`.text.typemap` argument. [ticket:2932]
* - better way to do itMike Bayer2014-01-291-2/+4
|
* - add TypeError handling to the tests here, ensure TypeErrorMike Bayer2014-01-291-8/+15
| | | | | for the control is a TypeError for the row, as is raised on py3k when less/greater operators are used on incompatible types
* - Fixed 0.9 regression where the new sortable support for :class:`.RowProxy`Mike Bayer2014-01-281-1/+25
| | | | | | | | | would lead to ``TypeError`` when compared to non-tuple types as it attempted to apply tuple() to the "other" object unconditionally. The full range of Python comparison operators have now been implemented on :class:`.RowProxy`, using an approach that guarantees a comparison system that is equivalent to that of a tuple, and the "other" object is only coerced if it's an instance of RowProxy. [ticket:2924]
* - Fixed bug where SQL statement would be improperly ASCII-encodedMike Bayer2013-11-221-1/+1
| | | | | | | when a pre-DBAPI :class:`.StatementError` were raised within :meth:`.Connection.execute`, causing encoding errors for non-ASCII statements. The stringification now remains within Python unicode thus avoiding encoding errors. [ticket:2871]
* - The :class:`.RowProxy` object is now sortable in Python as a regularMike Bayer2013-11-191-0/+13
| | | | | | tuple is; this is accomplished via ensuring tuple() conversion on both sides within the ``__eq__()`` method as well as the addition of a ``__lt__()`` method. [ticket:2848]
* - remove informix dialect, moved out to ↵Mike Bayer2013-11-171-3/+0
| | | | | | https://bitbucket.org/zzzeek/sqlalchemy_informixdb - remove informix, maxdb, access symbols from tests etc.
View Lorry Controller Status