summaryrefslogtreecommitdiff
path: root/test/sql/test_query.py
Commit message (Collapse)AuthorAgeFilesLines
...
* - 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.
* - we dont actually need this unicode cast, on py3k + linux it seems theMike Bayer2013-07-091-0/+2
| | | | | has_table issues are OK. On OSX forget it. - still some issues with PY3k + pyodbc + decimal values it doesn't expect, not sure
* add an ORDER BY hereMike Bayer2013-06-261-2/+2
|
* - some tweaks to try to help out mssql+pyodbc support a bit, py3k is reallyMike Bayer2013-06-031-2/+0
| | | | not happening too well (I need to stick with linux + freetds 0.91, I know)
* - the raw 2to3 runMike Bayer2013-04-271-21/+21
| | | | - went through examples/ and cleaned out excess list() calls
* A major fix to the way in which a select() object producesMike Bayer2013-04-111-0/+16
| | | | | | | | | | | | | | | | | | | labeled columns when apply_labels() is used; this mode produces a SELECT where each column is labeled as in <tablename>_<columnname>, to remove column name collisions for a multiple table select. The fix is that if two labels collide when combined with the table name, i.e. "foo.bar_id" and "foo_bar.id", anonymous aliasing will be applied to one of the dupes. This allows the ORM to handle both columns independently; previously, 0.7 would in some cases silently emit a second SELECT for the column that was "duped", and in 0.8 an ambiguous column error would be emitted. The "keys" applied to the .c. collection of the select() will also be deduped, so that the "column being replaced" warning will no longer emit for any select() that specifies use_labels, though the dupe key will be given an anonymous label which isn't generally user-friendly. [ticket:2702]
* fix syntax errorMike Bayer2013-03-241-1/+1
|
* Fixed bug whereby a DBAPI that can return "0"Mike Bayer2013-03-231-1/+18
| | | | | for cursor.lastrowid would not function correctly in conjunction with :attr:`.ResultProxy.inserted_primary_key`.
* - add support for pulling in an external requirements fileMike Bayer2013-02-061-9/+14
| | | | - start filling in default versions of remaining requirements that are still only in test/
* - add an "empty_inserts" requirement target plus a suite testMike Bayer2013-02-061-3/+3
| | | | - add suite tests for basic explicit Sequence support, result-row column access (tests that name_normalize is set correctly among many other things)
* internally at least refer to multirow as "multivalues", to distinguish betweenMike Bayer2012-12-081-2/+2
| | | | | an INSERT that's used in executemany() as opposed to one which has a VALUES clause with multiple entries.
* - multivalued inserts, [ticket:2623]Mike Bayer2012-12-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - update "not supported" messages for empty inserts, mutlivalue inserts - rework the ValuesBase approach for multiple value sets so that stmt.parameters does store a list for multiple values; the _has_multiple_parameters flag now indicates which of the two modes the statement is within. it now raises exceptions if a subsequent call to values() attempts to call a ValuesBase with one mode in the style of the other mode; that is, you can't switch a single- or multi- valued ValuesBase to the other mode, and also if a multiple value is passed simultaneously with a kwargs set. Added tests for these error conditions - Calling values() multiple times in multivalue mode now extends the parameter list to include the new parameter sets. - add error/test if multiple *args were passed to ValuesBase.values() - rework the compiler approach for multivalue inserts, back to where _get_colparams() returns the same list of (column, value) as before, thereby maintaining the identical number of append() and other calls when multivalue is not enabled. In the case of multivalue, it makes a last-minute switch to return a list of lists instead of the single list. As it constructs the additional lists, the inline defaults and other calculated default parameters of the first parameter set are copied into the newly generated lists so that these features continue to function for a multivalue insert. Multivalue inserts now add no additional function calls to the compilation for regular insert constructs. - parameter lists for multivalue inserts now includes an integer index for all parameter sets. - add detailed documentation for ValuesBase.values(), including careful wording to describe the difference between multiple values and an executemany() call. - add a test for multivalue insert + returning - it works ! - remove the very old/never used "postgresql_returning"/"firebird_returning" flags.
* compiler: add support for multirow insertsIdan Kamara2012-12-061-0/+11
| | | | | | | | | | | | | | | | | | | | | Some databases support this syntax for inserts: INSERT INTO table (id, name) VALUES ('v1', 'v2'), ('v3', 'v4'); which greatly increases INSERT speed. It is now possible to pass a list of lists/tuples/dictionaries as the values param to the Insert construct. We convert it to a flat dictionary so we can continue using bind params. The above query will be converted to: INSERT INTO table (id, name) VALUES (:id, :name), (:id0, :name0); Currently only supported on postgresql, mysql and sqlite.
* Fixed bug whereby using "key" with ColumnMike Bayer2012-11-131-0/+21
| | | | | | | | in conjunction with "schema" for the owning Table would fail to locate result rows due to the MSSQL dialect's "schema rendering" logic's failure to take .key into account. Also in 0.7.10. [ticket:2607]
* - [feature] The Query can now load entity/scalar-mixedMike Bayer2012-10-151-1/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | "tuple" rows that contain types which aren't hashable, by setting the flag "hashable=False" on the corresponding TypeEngine object in use. Custom types that return unhashable types (typically lists) can set this flag to False. [ticket:2592] - [bug] Applying a column expression to a select statement using a label with or without other modifying constructs will no longer "target" that expression to the underlying Column; this affects ORM operations that rely upon Column targeting in order to retrieve results. That is, a query like query(User.id, User.id.label('foo')) will now track the value of each "User.id" expression separately instead of munging them together. It is not expected that any users will be impacted by this; however, a usage that uses select() in conjunction with query.from_statement() and attempts to load fully composed ORM entities may not function as expected if the select() named Column objects with arbitrary .label() names, as these will no longer target to the Column objects mapped by that entity. [ticket:2591]
* - more tests, move some tests out of test_reflection, test_queryMike Bayer2012-09-271-78/+8
|
* trying different approaches to test layout. in this one, the testing modulesMike Bayer2012-09-271-4/+6
| | | | | | | become an externally usable package but still remains within the main sqlalchemy parent package. in this system, we use kind of an ugly hack to get the noseplugin imported outside of the "sqlalchemy" package, while still making it available within sqlalchemy for usage by third party libraries.
* - got firebird runningMike Bayer2012-09-231-5/+3
| | | | | | | | | | | | - add some failure cases - [bug] Firebird now uses strict "ansi bind rules" so that bound parameters don't render in the columns clause of a statement - they render literally instead. - [bug] Support for passing datetime as date when using the DateTime type with Firebird; other dialects support this.
* finished fixes for mxodbc; need to use at least version 3.2.1Mike Bayer2012-09-211-1/+0
|
* - fixes for mxODBC, some pyodbcMike Bayer2012-09-021-3/+28
| | | | | | - enhancements to test suite including ability to set up a testing engine for a whole test class, fixes to how noseplugin sets up/tears down per-class context
* - [bug] Fixed a regression since 0.6 regardingMike Bayer2012-08-311-4/+26
| | | | | | | | | | | | | | | | result-row targeting. It should be possible to use a select() statement with string based columns in it, that is select(['id', 'name']).select_from('mytable'), and have this statement be targetable by Column objects with those names; this is the mechanism by which query(MyClass).from_statement(some_statement) works. At some point the specific case of using select(['id']), which is equivalent to select([literal_column('id')]), stopped working here, so this has been re-instated and of course tested. [ticket:2558]
* - [feature] The "required" flag is set toMike Bayer2012-08-271-1/+62
| | | | | | | | | | True by default, if not passed explicitly, on bindparam() if the "value" or "callable" parameters are not passed. This will cause statement execution to check for the parameter being present in the final collection of bound parameters, rather than implicitly assigning None. [ticket:2556]
* - fix for pypyMike Bayer2012-08-251-0/+2
| | | | - more oracle fixes
* small tweaks to make insert() behavior more consistent, mostly tests, ↵Mike Bayer2012-08-231-0/+149
| | | | [ticket:2461]
* - [bug] Fixed cextension bug whereby theMike Bayer2012-08-221-2/+64
| | | | | | | | | | | | | | | | | | | "ambiguous column error" would fail to function properly if the given index were a Column object and not a string. Note there are still some column-targeting issues here which are fixed in 0.8. [ticket:2553] - find more cases where column targeting is being inaccurate, add more information to result_map to better differentiate "ambiguous" results from "present" or "not present". In particular, result_map is sensitive to dupes, even though no error is raised; the conflicting columns are added to the "obj" member of the tuple so that the two are both directly accessible in the result proxy - handwringing over the damn "name fallback" thing in results. can't really make it perfect yet - fix up oracle returning clause. not sure why its guarding against labels, remove that for now and see what the bot says.
* fixes for pg9Mike Bayer2012-08-221-1/+1
|
* - all tests passMike Bayer2012-08-131-8/+0
|
* - break out engine/base.py into base, interfaces, result, util.Mike Bayer2012-08-071-6/+6
| | | | - remove deprecated 0.7 engine methods
* -whitespace bonanza, contdMike Bayer2012-07-281-24/+24
|
* remove this test now covered in test_executeMike Bayer2012-06-161-8/+0
|
* - [feature] Added SQLite execution optionMike Bayer2012-05-041-11/+64
| | | | | | | "sqlite_raw_colnames=True", will bypass attempts to remove "." from column names returned by SQLite cursor.description. [ticket:2475]
* - [feature] The behavior of column targetingMike Bayer2012-04-241-4/+28
| | | | | | | | | | | | | | in result sets is now case sensitive by default. SQLAlchemy for many years would run a case-insensitive conversion on these values, probably to alleviate early case sensitivity issues with dialects like Oracle and Firebird. These issues have been more cleanly solved in more modern versions so the performance hit of calling lower() on identifiers is removed. The case insensitive comparisons can be re-enabled by setting "case_insensitive=False" on create_engine(). [ticket:2423]
* - [bug] The names of the columns on theMike Bayer2012-04-241-37/+1
| | | | | | | | .c. attribute of a select().apply_labels() is now based on <tablename>_<colkey> instead of <tablename>_<colname>, for those columns that have a distinctly named .key. [ticket:2397]
* - [bug] Fixed issue whereby attribute-basedMike Bayer2012-03-141-0/+13
| | | | | | | | column access on a row would raise AttributeError with non-C version, NoSuchColumnError with C version. Now raises AttributeError in both cases. [ticket:2398]
* hey pyodbc fixed this, hoopde dooMike Bayer2012-03-131-1/+0
|
* - [bug] Added support for using the .keyMike Bayer2012-02-051-1/+163
| | | | | | | | | | | | of a Column as a string identifier in a result set row. The .key is currently listed as an "alternate" name for a column, and is superseded by the name of a column which has that key value as its regular name. For the next major release of SQLAlchemy we may reverse this precedence so that .key takes precedence, but this is not decided on yet. [ticket:2392]
View Lorry Controller Status