summaryrefslogtreecommitdiff
path: root/test/sql/test_operators.py
Commit message (Collapse)AuthorAgeFilesLines
...
* Deprecate empty or_() and and_()Federico Caselli2020-01-251-4/+59
| | | | | | | | | | | | | | | | | | | | | | | Creating an :func:`.and_` or :func:`.or_` construct with no arguments or empty ``*args`` will now emit a deprecation warning, as the SQL produced is a no-op (i.e. it renders as a blank string). This behavior is considered to be non-intuitive, so for empty or possibly empty :func:`.and_` or :func:`.or_` constructs, an appropriate default boolean should be included, such as ``and_(True, *args)`` or ``or_(False, *args)``. As has been the case for many major versions of SQLAlchemy, these particular boolean values will not render if the ``*args`` portion is non-empty. As there are some internal cases where an empty and_() construct is used in order to build an optional WHERE expression, a private utility function is added to suit this use case. Co-authored-by: Mike Bayer <mike_mp@zzzcomputing.com> Fixes: #5054 Closes: #5062 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/5062 Pull-request-sha: 5ca2f27281977d74e390148c0fb8deaa0e0e4ad9 Change-Id: I599b9c8befa64d9a59a35ad7dd84ff400e3aa647
* apply asbool reduction to the onclause in join()Mike Bayer2020-01-171-0/+37
| | | | | | | | | | The :func:`.true` and :func:`.false` operators may now be applied as the "onclause" of a :func:`.sql.join` on a backend that does not support "native boolean" expressions, e.g. Oracle or SQL Server, and the expression will render as "1=1" for true and "1=0" false. This is the behavior that was introduced many years ago in :ticket:`2804` for and/or expressions. Change-Id: I85311c31c22d6e226c618f8840f6b95eca611153
* Use expanding IN for all literal value IN expressionsMike Bayer2019-12-221-93/+47
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Add type accessors for JSON indexed/pathed element accessMike Bayer2019-11-111-0/+42
| | | | | | | | | | | | | | | Added new accessors to expressions of type :class:`.JSON` to allow for specific datatype access and comparison, covering strings, integers, numeric, boolean elements. This revises the documented approach of CASTing to string when comparing values, instead adding specific functionality into the PostgreSQL, SQlite, MySQL dialects to reliably deliver these basic types in all cases. The change also delivers a new feature to the test exclusions system so that combinations and exclusions can be used together. Fixes: #4276 Change-Id: Ica5a926c060feb40a0a7cd60b9d6e061d7825728
* Add anonymizing context to cache keys, comparison; convert traversalMike Bayer2019-11-041-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Created new visitor system called "internal traversal" that applies a data driven approach to the concept of a class that defines its own traversal steps, in contrast to the existing style of traversal now known as "external traversal" where the visitor class defines the traversal, i.e. the SQLCompiler. The internal traversal system now implements get_children(), _copy_internals(), compare() and _cache_key() for most Core elements. Core elements with special needs like Select still implement some of these methods directly however most of these methods are no longer explicitly implemented. The data-driven system is also applied to ORM elements that take part in SQL expressions so that these objects, like mappers, aliasedclass, query options, etc. can all participate in the cache key process. Still not considered is that this approach to defining traversibility will be used to create some kind of generic introspection system that works across Core / ORM. It's also not clear if real statement caching using the _cache_key() method is feasible, if it is shown that running _cache_key() is nearly as expensive as compiling in any case. Because it is data driven, it is more straightforward to optimize using inlined code, as is the case now, as well as potentially using C code to speed it up. In addition, the caching sytem now accommodates for anonymous name labels, which is essential so that constructs which have anonymous labels can be cacheable, that is, their position within a statement in relation to other anonymous names causes them to generate an integer counter relative to that construct which will be the same every time. Gathering of bound parameters from any cache key generation is also now required as there is no use case for a cache key that does not extract bound parameter values. Applies-to: #4639 Change-Id: I0660584def8627cad566719ee98d3be045db4b8d
* Implement facade for pytest parametrize, fixtures, classlevelMike Bayer2019-10-201-188/+127
| | | | | | | | | | | | | | | | | | | Add factilities to implement pytest.mark.parametrize and pytest.fixtures patterns, which largely resemble things we are already doing. Ensure a facade is used, so that the test suite remains independent of py.test, but also tailors the functions to the more limited scope in which we are using them. Additionally, create a class-based version that works from the same facade. Several old polymorphic tests as well as two of the sql test are refactored to use the new features. Change-Id: I6ef8af1dafff92534313016944d447f9439856cf References: #4896
* SelectBase no longer a FromClauseMike Bayer2019-07-061-1/+11
| | | | | | | | | | | | | | | | | | | | 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
* Implement new ClauseElement role and coercion systemMike Bayer2019-05-181-15/+58
| | | | | | | | | | | | | | | | | | | | A major refactoring of all the functions handle all detection of Core argument types as well as perform coercions into a new class hierarchy based on "roles", each of which identify a syntactical location within a SQL statement. In contrast to the ClauseElement hierarchy that identifies "what" each object is syntactically, the SQLRole hierarchy identifies the "where does it go" of each object syntactically. From this we define a consistent type checking and coercion system that establishes well defined behviors. This is a breakout of the patch that is reorganizing select() constructs to no longer be in the FromClause hierarchy. Also includes a rename of as_scalar() into scalar_subquery(); deprecates automatic coercion to scalar_subquery(). Partially-fixes: #4617 Change-Id: I26f1e78898693c6b99ef7ea2f4e7dfd0e8e1a1bd
* Reimplement .compare() in terms of a visitorMike Bayer2019-04-291-2/+15
| | | | | | | | | | | | Reworked the :meth:`.ClauseElement.compare` methods in terms of a new visitor-based approach, and additionally added test coverage ensuring that all :class:`.ClauseElement` subclasses can be accurately compared against each other in terms of structure. Structural comparison capability is used to a small degree within the ORM currently, however it also may form the basis for new caching features. Fixes: #4336 Change-Id: I581b667d8e1642a6c27165cc9f4aded1c66effc6
* negate True/False separately from other elementsMike Bayer2019-04-181-0/+16
| | | | | | | | | Fixed issue where double negation of a boolean column wouldn't reset the "NOT" operator. Fixes: #4618 Change-Id: Ica280a0d6b5b0870aa2d05c4d059a1e559e6b12a (cherry picked from commit 18f25f50353d9736e6638266585b2cb3ef7b0ea4)
* Fix many spell glitchesLele Gaifax2019-01-251-2/+2
| | | | | | | | | | | | This affects mostly docstrings, except in orm/events.py::dispose_collection() where one parameter gets renamed: given that the method is empty, it seemed reasonable to me to fix that too. Closes: #4440 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/4440 Pull-request-sha: 779ed75acb6142e1f1daac467b5b14134529bb4b Change-Id: Ic0553fe97853054b09c2453af76d96363de6eb0e
* Post black reformattingMike Bayer2019-01-061-60/+65
| | | | | | | | | | | | | 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-1049/+978
| | | | | | | | | | | | | | 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
* Add concept of "implicit boolean", treat as nativeMike Bayer2018-08-151-1/+33
| | | | | | | | | | | | | | | Fixed issue that is closely related to :ticket:`3639` where an expression rendered in a boolean context on a non-native boolean backend would be compared to 1/0 even though it is already an implcitly boolean expression, when :meth:`.ColumnElement.self_group` were used. While this does not affect the user-friendly backends (MySQL, SQLite) it was not handled by Oracle (and possibly SQL Server). Whether or not the expression is implicitly boolean on any database is now determined up front as an additional check to not generate the integer comparison within the compliation of the statement. Fixes: #4320 Change-Id: Iae0a65e5c01bd576e64733c3651e1e1a1a1b240c
* Fix collections ABC access before Python 3.8Nathaniel Knight2018-08-011-1/+1
| | | | | | | | | | | | | | | | | | | | Started importing "collections" from "collections.abc" under Python 3.3 and greater for Python 3.8 compatibility. Pull request courtesy Nathaniel Knight. In Python 3.3, the abstract base classes (Iterable, Mapping, etc.) were moved from the `collections` module and put in the `collections.abc` module. They remain in the `collections` module for backwards compatibility, and will until Python 3.8. This commit adds a variable (`collections_abc`) to the `util/compat` module, which will be the `collections` module for Python < 3.3 and before, or the `collections.abc` module for Python >= 3.3. It also uses the new variable, getting rid of some deprecation warnings that were seen when running under Python 3.7. Change-Id: I2d1c0ef97c8ecac7af152cc56263422a40faa6bb Pull-request: https://github.com/zzzeek/sqlalchemy/pull/464
* Rework autoescape to be a simple boolean; escape the escape characterMike Bayer2017-10-241-18/+49
| | | | | | | | | | | | Reworked the new "autoescape" feature introduced in :ref:`change_2694` in 1.2.0b2 to be fully automatic; the escape character now defaults to a forwards slash ``"/"`` and is applied to percent, underscore, as well as the escape character itself, for fully automatic escaping. The character can also be changed using the "escape" parameter. Change-Id: I74894a2576983c0f6eb89480c9e5727f49fa9c25 Fixes: #2694
* Support method form of any_(), all_()Mike Bayer2017-09-271-0/+38
| | | | | | | | | | | | Fixed bug where the recently added :meth:`.ColumnOperators.any_` and :meth:`.ColumnOperators.all_` methods didn't work when called as methods, as opposed to using the standalone functions :func:`~.expression.any_` and :func:`~.expression.all_`. Also added documentation examples for these relatively unintuitive SQL operators. Change-Id: I3e56b463e9fd146a077b9970624f50cba27f9811 Fixes: #4093
* Ensure custom ops have consistent typing behavior, boolean supportMike Bayer2017-09-011-2/+31
| | | | | | | | | | | | | | Refined the behavior of :meth:`.Operators.op` such that in all cases, if the :paramref:`.Operators.op.is_comparison` flag is set to True, the return type of the resulting expression will be :class:`.Boolean`, and if the flag is False, the return type of the resulting expression will be the same type as that of the left-hand expression, which is the typical default behavior of other operators. Also added a new parameter :paramref:`.Operators.op.return_type` as well as a helper method :meth:`.Operators.bool_op`. Change-Id: Ifc8553cd4037d741b84b70a9702cbd530f1a9de0 Fixes: #4063
* Flatten operator precedence for comparison operatorsMichael Birtwell2017-05-251-0/+7
| | | | | | | | | | | | | | | The operator precedence for all comparison operators such as LIKE, IS, IN, MATCH, equals, greater than, less than, etc. has all been merged into one level, so that expressions which make use of these against each other will produce parentheses between them. This suits the stated operator precedence of databases like Oracle, MySQL and others which place all of these operators as equal precedence, as well as Postgresql as of 9.5 which has also flattened its operator precendence. Co-authored-by: Mike Bayer <mike_mp@zzzcomputing.com> Fixes: #3999 Change-Id: I3f3d5124a64af0d376361cdf15a97e2e703be56f Pull-request: https://github.com/zzzeek/sqlalchemy/pull/367
* Enforce boolean result type for all eq_, is_, isnot, comparisonMike Bayer2017-04-271-0/+10
| | | | | | | | | | | | Repaired issue where the type of an expression that used :meth:`.ColumnOperators.is_` or similar would not be a "boolean" type, instead the type would be "nulltype", as well as when using custom comparison operators against an untyped expression. This typing can impact how the expression behaves in larger contexts as well as in result-row-handling. Change-Id: Ib810ff686de500d8db26ae35a51005fab29603b6 Fixes: #3873
* Add _negate() to Label to negate inner elementMike Bayer2017-04-211-1/+15
| | | | | | | | | Fixed the negation of a :class:`.Label` construct so that the inner element is negated correctly, when the :func:`.not_` modifier is applied to the labeled expression. Change-Id: Ia99917b2959bdfbff28689c962b4203911c57b85 Fixes: #3969
* Add new "expanding" feature to bindparam()Mike Bayer2017-04-071-3/+3
| | | | | | | | | | | | | | | | 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
* Double percent signs based on paramstyle, not dialectMike Bayer2017-04-051-24/+24
| | | | | | | | | | | | This patch moves the "doubling" of percent signs into the base compiler and makes it completely a product of whether or not the paramstyle is format/pyformat or not. Without this paramstyle, percent signs are not doubled across text(), literal_column(), and column(). Change-Id: Ie2f278ab1dbb94b5078f85c0096d74dbfa049197 Fixes: #3740
* Treat collation names as identifiersMike Bayer2017-03-231-8/+8
| | | | | | | | | | | The expression used for COLLATE as rendered by the column-level :func:`.expression.collate` and :meth:`.ColumnOperators.collate` is now quoted as an identifier when the name is case sensitive, e.g. has uppercase characters. Note that this does not impact type-level collation, which is already quoted. Change-Id: I83d5d9cd1e66a4f20b96303bb84c5f360d5d6a1a Fixes: #3785
* Add "empty in" strategies; default to "static"Mike Bayer2017-03-141-11/+49
| | | | | | | | | | | | | | | 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
* add autoescape option to startswith, endswith, and containsDiana Clarke2017-03-141-13/+111
| | | | | | Fixes: #2694 Change-Id: I34c0bdcb01c2b76b9ab6cd315dae13e3dd8a502b Pull-request: https://github.com/zzzeek/sqlalchemy/pull/207
* Make all tests to be PEP8 compliantKhairi Hafsham2017-02-071-13/+15
| | | | | | | | tested using pycodestyle version 2.2.0 Fixes: #3885 Change-Id: I5df43adc3aefe318f9eeab72a078247a548ec566 Pull-request: https://github.com/zzzeek/sqlalchemy/pull/343
* Add "eager_parenthesis" late-compilation rule, use w/ PG JSON/HSTOREMike Bayer2016-10-011-2/+27
| | | | | | | | | | | | Added compiler-level flags used by Postgresql to place additional parenthesis than would normally be generated by precedence rules around operations involving JSON, HSTORE indexing operators as well as within their operands since it has been observed that Postgresql's precedence rules for at least the HSTORE indexing operator is not consistent between 9.4 and 9.5. Fixes: #3806 Change-Id: I5899677b330595264543b055abd54f3c76bfabf2
* Exclude eq and ne from associative operatorsJohn Passaro2016-09-191-0/+8
| | | | | | | | | | | | The "eq" and "ne" operators are no longer part of the list of "associative" operators, while they remain considered to be "commutative". This allows an expression like ``(x == y) == z`` to be maintained at the SQL level with parenthesis. Pull request courtesy John Passaro. Fixes: #3799 Change-Id: I3759d8987b35649d7418b6524316c9e70c857e68 Pull-request: https://github.com/zzzeek/sqlalchemy/pull/308
* Preserve type for math negationMike Bayer2016-07-011-0/+6
| | | | | | | | | | Fixed issue in SQL math negation operator where the type of the expression would no longer be the numeric type of the original. This would cause issues where the type determined result set behaviors. Change-Id: If0e339614a3686e251235fc94b6f59310c4630a5 Fixes: #3735
* Add IS (NOT) DISTINCT FROM operatorsSebastian Bank2016-06-061-0/+66
| | | | | | | | | | | None / True / False render as literals. For SQLite, "IS" is used as SQLite lacks "IS DISTINCT FROM" but its "IS" operator acts this way for NULL. Doctext-author: Mike Bayer <mike_mp@zzzcomputing.com> Change-Id: I9227b81f7207b42627a0349d14d40b46aa756cce Pull-request: https://github.com/zzzeek/sqlalchemy/pull/248
* - Fixed issue where inadvertent use of the Python ``__contains__``Mike Bayer2016-02-021-1/+23
| | | | | | | | | override with a column expression (e.g. by using ``'x' in col``) would cause an endless loop in the case of an ARRAY type, as Python defers this to ``__getitem__`` access which never raises for this type. Overall, all use of ``__contains__`` now raises NotImplementedError. fixes #3642
* - Added :class:`.mysql.JSON` for MySQL 5.7. The JSON type providesMike Bayer2016-01-061-24/+125
| | | | | | | | | | | | | | | | | | | | | | | | | | persistence of JSON values in MySQL as well as basic operator support of "getitem" and "getpath", making use of the ``JSON_EXTRACT`` function in order to refer to individual paths in a JSON structure. fixes #3547 - Added a new type to core :class:`.types.JSON`. This is the base of the PostgreSQL :class:`.postgresql.JSON` type as well as that of the new :class:`.mysql.JSON` type, so that a PG/MySQL-agnostic JSON column may be used. The type features basic index and path searching support. fixes #3619 - reorganization of migration docs etc. to try to refer both to the fixes to JSON that helps Postgresql while at the same time indicating these are new features of the new base JSON type. - a rework of the Array/Indexable system some more, moving things that are specific to Array out of Indexable. - new operators for JSON indexing added to core so that these can be compiled by the PG and MySQL dialects individually - rename sqltypes.Array to sqltypes.ARRAY - as there is no generic Array implementation, this is an uppercase type for now, consistent with the new sqltypes.JSON type that is also not a generic implementation. There may need to be some convention change to handle the case of datatypes that aren't generic, rely upon DB-native implementations, but aren't necessarily all named the same thing.
* - build out a new base type for Array, as well as new any/all operatorsMike Bayer2015-08-251-2/+154
| | | | | | - any/all work for Array as well as subqueries, accepted by MySQL - Postgresql ARRAY now subclasses Array - fixes #3516
* - as the Concatenable mixin was changed to support calling down toMike Bayer2015-08-181-1/+55
| | | | | | | | | | | | "super" instead of hardcoding to "self.type" for the default return value, the base Comparator was returning other_comparator.type. It's not clear what the rationale for this was, though in theory the base Comparator should possibly even throw an exception if the two types aren't the same (or of the same affinity?) . - mysql.SET was broken on this because the bitwise version adds "0" to the value to force an integer within column_expression, we are doing type_coerces here now in any case so that there is no type ambiguity for this operation
* - merge of ticket_3499 indexed access branchMike Bayer2015-08-171-2/+196
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - The "hashable" flag on special datatypes such as :class:`.postgresql.ARRAY`, :class:`.postgresql.JSON` and :class:`.postgresql.HSTORE` is now set to False, which allows these types to be fetchable in ORM queries that include entities within the row. fixes #3499 - The Postgresql :class:`.postgresql.ARRAY` type now supports multidimensional indexed access, e.g. expressions such as ``somecol[5][6]`` without any need for explicit casts or type coercions, provided that the :paramref:`.postgresql.ARRAY.dimensions` parameter is set to the desired number of dimensions. fixes #3487 - The return type for the :class:`.postgresql.JSON` and :class:`.postgresql.JSONB` when using indexed access has been fixed to work like Postgresql itself, and returns an expression that itself is of type :class:`.postgresql.JSON` or :class:`.postgresql.JSONB`. Previously, the accessor would return :class:`.NullType` which disallowed subsequent JSON-like operators to be used. part of fixes #3503 - The :class:`.postgresql.JSON`, :class:`.postgresql.JSONB` and :class:`.postgresql.HSTORE` datatypes now allow full control over the return type from an indexed textual access operation, either ``column[someindex].astext`` for a JSON type or ``column[someindex]`` for an HSTORE type, via the :paramref:`.postgresql.JSON.astext_type` and :paramref:`.postgresql.HSTORE.text_type` parameters. also part of fixes #3503 - The :attr:`.postgresql.JSON.Comparator.astext` modifier no longer calls upon :meth:`.ColumnElement.cast` implicitly, as PG's JSON/JSONB types allow cross-casting between each other as well. Code that makes use of :meth:`.ColumnElement.cast` on JSON indexed access, e.g. ``col[someindex].cast(Integer)``, will need to be changed to call :attr:`.postgresql.JSON.Comparator.astext` explicitly. This is part of the refactor in references #3503 for consistency in operator use.
* - Fixed bug where coersion of literal ``True`` or ``False`` constantMike Bayer2015-07-191-0/+58
| | | | | | in conjunction with :func:`.and_` or :func:`.or_` would fail with an AttributeError. fixes #3490
* Added test for modulo operator.pr/188Dan Gittik2015-07-171-0/+3
|
* - start trying to move things into __slots__. This seems to reduce theslotsMike Bayer2015-01-041-7/+9
| | | | | size of the many per-column objects we're hitting, but somehow the overall memory is hardly being reduced at all in initial testing
* - Fixed bug where using a :class:`.TypeDecorator` that implementedMike Bayer2014-12-191-0/+25
| | | | | | | a type that was also a :class:`.TypeDecorator` would fail with Python's "Cannot create a consistent method resolution order (MRO)" error, when any kind of SQL comparison expression were used against an object using this type.
* - The :meth:`.Operators.match` operator is now handled such that theMike Bayer2014-12-041-1/+27
| | | | | | | | | | | | | | | | return type is not strictly assumed to be boolean; it now returns a :class:`.Boolean` subclass called :class:`.MatchType`. The type will still produce boolean behavior when used in Python expressions, however the dialect can override its behavior at result time. In the case of MySQL, while the MATCH operator is typically used in a boolean context within an expression, if one actually queries for the value of a match expression, a floating point value is returned; this value is not compatible with SQLAlchemy's C-based boolean processor, so MySQL's result-set behavior now follows that of the :class:`.Float` type. A new operator object ``notmatch_op`` is also added to better allow dialects to define the negation of a match operation. fixes #3263
* - Reversing a change that was made in 0.9, the "singleton" natureMike Bayer2014-10-191-1/+20
| | | | | | | | | of the "constants" :func:`.null`, :func:`.true`, and :func:`.false` has been reverted. These functions returning a "singleton" object had the effect that different instances would be treated as the same regardless of lexical use, which in particular would impact the rendering of the columns clause of a SELECT statement. fixes #3170
* - update the flake8 rules againMike Bayer2014-07-181-242/+333
| | | | - apply autopep8 + manual fixes to most of test/sql/
* - Fixed a bug within the custom operator plus :meth:`.TypeEngine.with_variant`Mike Bayer2014-06-271-1/+30
| | | | | | system, whereby using a :class:`.TypeDecorator` in conjunction with variant would fail with an MRO error when a comparison operator was used. fixes #3102
* - Fixed bug where the :meth:`.Operators.__and__`,Mike Bayer2014-05-241-0/+49
| | | | | | | :meth:`.Operators.__or__` and :meth:`.Operators.__invert__` operator overload methods could not be overridden within a custom :class:`.TypeEngine.Comparator` implementation. fixes #3012
* - Fixes to the newly enhanced boolean coercion in :ticket:`2804` whereMike Bayer2014-04-011-3/+27
| | | | | | | the new rules for "where" and "having" woudn't take effect for the "whereclause" and "having" kw arguments of the :func:`.select` construct, which is also what :class:`.Query` uses so wasn't working in the ORM either. fixes #3013 re: #2804
* - Added new flag :paramref:`.expression.between.symmetric`, when set to TrueMike Bayer2014-03-301-3/+43
| | | | | | | renders "BETWEEN SYMMETRIC". Also added a new negation operator "notbetween_op", which now allows an expression like ``~col.between(x, y)`` to render as "col NOT BETWEEN x AND y", rather than a parentheiszed NOT string. fixes #2990
* - Fixed bug in :func:`.tuple_` construct where the "type" of essentiallyMike Bayer2014-02-271-1/+21
| | | | | | | | | | | the first SQL expression would be applied as the "comparison type" to a compared tuple value; this has the effect in some cases of an inappropriate "type coersion" occurring, such as when a tuple that has a mix of String and Binary values improperly coerces target values to Binary even though that's not what they are on the left side. :func:`.tuple_` now expects heterogeneous types within its list of values. fixes #2977
* - Fixed bug where :meth:`.in_()` would go into an endless loop ifMike Bayer2014-02-131-0/+33
| | | | | | erroneously passed a column expression whose comparator included the ``__getitem__()`` method, such as a column that uses the :class:`.postgresql.ARRAY` type. [ticket:2957]
* - Added a new parameter :paramref:`.Operators.op.is_comparison`. ThisMike Bayer2014-01-311-0/+10
| | | | | | flag allows a custom op from :meth:`.Operators.op` to be considered as a "comparison" operator, thus usable for custom :paramref:`.relationship.primaryjoin` conditions.