summaryrefslogtreecommitdiff
path: root/test/dialect/test_sqlite.py
Commit message (Collapse)AuthorAgeFilesLines
...
* Add future=True to create_engine/Session; unify select()Mike Bayer2020-07-081-63/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Several weeks of using the future_select() construct has led to the proposal there be just one select() construct again which features the new join() method, and otherwise accepts both the 1.x and 2.x argument styles. This would make migration simpler and reduce confusion. However, confusion may be increased by the fact that select().join() is different Current thinking is we may be better off with a few hard behavioral changes to old and relatively unknown APIs rather than trying to play both sides within two extremely similar but subtly different APIs. At the moment, the .join() thing seems to be the only behavioral change that occurs without the user taking any explicit steps. Session.execute() will still behave the old way as we are adding a future flag. This change also adds the "future" flag to Session() and session.execute(), so that interpretation of the incoming statement, as well as that the new style result is returned, does not occur for existing applications unless they add the use of this flag. The change in general is moving the "removed in 2.0" system further along where we want the test suite to fully pass even if the SQLALCHEMY_WARN_20 flag is set. Get many tests to pass when SQLALCHEMY_WARN_20 is set; this should be ongoing after this patch merges. Improve the RemovedIn20 warning; these are all deprecated "since" 1.4, so ensure that's what the messages read. Make sure the inforamtion link is on all warnings. Add deprecation warnings for parameters present and add warnings to all FromClause.select() types of methods. Fixes: #5379 Fixes: #5284 Change-Id: I765a0b912b3dcd0e995426427d8bb7997cbffd51 References: #5159
* Add 'exists' to SQLite's reserved keywordsThodoris Sotiropoulos2020-06-111-0/+1
| | | | | | | | | | | | | Added "exists" to the list of reserved words for SQLite so that this word will be quoted when used as a label or column name. Pull request courtesy Thodoris Sotiropoulos. Fixes: #5395 Closes: #5396 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/5396 Pull-request-sha: 5608317a38db7b63115e3b467d182a3e5cc31580 Change-Id: Ia4769de2dec159dcf282eb4b30c11560da51a5c7
* Default create_constraint to FalseMike Bayer2020-06-031-1/+7
| | | | | | | | | | | | The :paramref:`.Enum.create_constraint` and :paramref:`.Boolean.create_constraint` parameters now default to False, indicating when a so-called "non-native" version of these two datatypes is created, a CHECK constraint will not be generated by default. These CHECK constraints present schema-management maintenance complexities that should be opted in to, rather than being turned on by default. Fixes: #5367 Change-Id: I0a3fb608ce32143fa757546cc17ba2013e93272a
* SQLite 3.31 added support for computed column.Federico Caselli2020-05-191-13/+16
| | | | | | | This change enables their support in SQLAlchemy when targeting SQLite. Fixes: #5297 Change-Id: Ia9f21a49e58fc977e3c669b8176036c95d93b9c8
* Clean up (engine|db).execute for sqliteGord Thompson2020-03-311-44/+46
| | | | Change-Id: Ie43e5b3a34ecc64ab77410e42f3e8de8bbc1e2d8
* Deprecate plain string in execute and introduce `exec_driver_sql`Federico Caselli2020-03-211-78/+102
| | | | | | | | | | | | | | | Execution of literal sql string is deprecated in the :meth:`.Connection.execute` and a warning is raised when used stating that it will be coerced to :func:`.text` in a future release. To execute a raw sql string the new connection method :meth:`.Connection.exec_driver_sql` was added, that will retain the previous behavior, passing the string to the DBAPI driver unchanged. Usage of scalar or tuple positional parameters in :meth:`.Connection.execute` is also deprecated. Fixes: #4848 Fixes: #5178 Change-Id: I2830181054327996d594f7f0d59c157d477c3aa9
* Result initial introductionMike Bayer2020-02-211-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Deprecate connection branchingMike Bayer2020-02-211-23/+22
| | | | | | | | | | | | | | | The :meth:`.Connection.connect` method is deprecated as is the concept of "connection branching", which copies a :class:`.Connection` into a new one that has a no-op ".close()" method. This pattern is oriented around the "connectionless execution" concept which is also being removed in 2.0. As part of this change we begin to move the internals away from "connectionless execution" overall. Remove the "connectionless execution" concept from the reflection internals and replace with explicit patterns at the Inspector level. Fixes: #5131 Change-Id: Id23d28a9889212ac5ae7329b85136157815d3e6f
* Fix test failures under WindowsFederico Caselli2019-12-311-31/+35
| | | | | | | | | | | | | | | | | Fixed a few test failures which would occur on Windows due to SQLite file locking issues, as well as some timing issues in connection pool related tests; pull request courtesy Federico Caselli. Note the pool related issues were fixed by Mike in I1a7162e67912d22c135fa517b687a073f8fd9151 but are being ticketed here. Fixes: #4946 Closes: #5055 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/5055 Pull-request-sha: 36925573aff828bbdd725a4fed5394e06c775a98 Change-Id: Ic53ec82f5d588d0e26a2d033a17c6109900d7f63
* Use expanding IN for all literal value IN expressionsMike Bayer2019-12-221-3/+21
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Support for generated columnsCaselIT2019-11-081-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | Added DDL support for "computed columns"; these are DDL column specifications for columns that have a server-computed value, either upon SELECT (known as "virtual") or at the point of which they are INSERTed or UPDATEd (known as "stored"). Support is established for Postgresql, MySQL, Oracle SQL Server and Firebird. Thanks to Federico Caselli for lots of work on this one. ORM round trip tests included. The ORM makes use of existing FetchedValue support and no additional ORM logic is present for the basic feature. It has been observed that Oracle RETURNING does not return the new value of a computed column upon UPDATE; it returns the prior value. As this is very dangerous, a warning is emitted if a computed column is rendered into the RETURNING clause of an UPDATE statement. Fixes: #4894 Closes: #4928 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/4928 Pull-request-sha: d39c521d5ac6ebfb4fb5b53846451de79752e64c Change-Id: I2610b2999a5b1b127ed927dcdaeee98b769643ce
* Drop right-nested join rewritingMike Bayer2019-10-071-0/+11
| | | | | | | | | | Dropped support for right-nested join rewriting to support old SQLite versions prior to 3.7.16, released in 2013. It is expected that all modern Python versions among those now supported should all include much newer versions of SQLite. Fixes: #4895 Change-Id: I7f0cfc2b7d988ff147b9a4c6d5e2adec87e27029
* Support SQLite URIsMike Bayer2019-09-211-7/+35
| | | | | | | | | Added support for sqlite "URI" connections, which allow for sqlite-specific flags to be passed in the query string such as "read only" for Python sqlite3 drivers that support this. Fixes: #4863 Change-Id: I7740b55ee8f2ede72a5c49ee94a7540e4d0250f2
* Reflect PK of referred table if referred columns not presentMike Bayer2019-08-181-0/+101
| | | | | | | | | | | | | | | Fixed bug where a FOREIGN KEY that was set up to refer to the parent table by table name only without the column names would not correctly be reflected as far as setting up the "referred columns", since SQLite's PRAGMA does not report on these columns if they weren't given explicitly. For some reason this was harcoded to assume the name of the local column, which might work for some cases but is not correct. The new approach reflects the primary key of the referred table and uses the constraint columns list as the referred columns list, if the remote column(s) aren't present in the reflected pragma directly. Fixes: #4810 Change-Id: I7789f83d68845ae197a782080af8ec64a7bf48cc
* Correct name for json_serializer / json_deserializer, document and testMike Bayer2019-08-081-0/+30
| | | | | | | | | | | | | The dialects that support json are supposed to take arguments ``json_serializer`` and ``json_deserializer`` at the create_engine() level, however the SQLite dialect calls them ``_json_serilizer`` and ``_json_deserilalizer``. The names have been corrected, the old names are accepted with a change warning, and these parameters are now documented as :paramref:`.create_engine.json_serializer` and :paramref:`.create_engine.json_deserializer`. Fixes: #4798 Change-Id: I1dbfe439b421fe9bb7ff3594ef455af8156f8851
* Always include a schema name in SQLite PRAGMAMike Bayer2019-08-021-2/+57
| | | | | | | | | | | | | | Fixed bug where usage of "PRAGMA table_info" in SQLite dialect meant that reflection features to detect for table existence, list of table columns, and list of foreign keys, would default to any table in any attached database, when no schema name was given and the table did not exist in the base schema. The fix explicitly runs PRAGMA for the 'main' schema and then the 'temp' schema if the 'main' returned no rows, to maintain the behavior of tables + temp tables in the "no schema" namespace, attached tables only in the "schema" namespace. Fixes: #4793 Change-Id: I75bc03ef42581c46b98987510d2d2e701df07412
* Support tuple IN VALUES for SQLite, othersMike Bayer2019-07-191-0/+8
| | | | | | | | | | | | Added support for composite (tuple) IN operators with SQLite, by rendering the VALUES keyword for this backend. As other backends such as DB2 are known to use the same syntax, the syntax is enabled in the base compiler using a dialect-level flag ``tuple_in_values``. The change also includes support for "empty IN tuple" expressions for SQLite when using "in_()" between a tuple value and an empty set. Fixes: #4766 Change-Id: I416e1af29b31d78f9ae06ec3c3a48ef6d6e813f5
* Reflect "NO ACTION" as None; support "RESTRICT"Mike Bayer2019-06-261-1/+1
| | | | | | | | | | | | | | The "NO ACTION" keyword for foreign key "ON UPDATE" is now considered to be the default cascade for a foreign key on all supporting backends (SQlite, MySQL, PostgreSQL) and when detected is not included in the reflection dictionary; this is already the behavior for PostgreSQL and MySQL for all previous SQLAlchemy versions in any case. The "RESTRICT" keyword is positively stored when detected; PostgreSQL does report on this keyword, and MySQL as of version 8.0 does as well. On earlier MySQL versions, it is not reported by the database. Fixes: #4741 Change-Id: I6becf1f2450605c1991158bb8a04d954dcc7396c
* Don't discard inactive transaction until it is explicitly rolled backMike Bayer2019-06-101-1/+3
| | | | | | | | | | | | | | | | | The :class:`.Connection` object will now not clear a rolled-back transaction until the outermost transaction is explicitly rolled back. This is essentially the same behavior that the ORM :class:`.Session` has had for a long time, where an explicit call to ``.rollback()`` on all enclosing transactions is required for the transaction to logically clear, even though the DBAPI-level transaction has already been rolled back. The new behavior helps with situations such as the "ORM rollback test suite" pattern where the test suite rolls the transaction back within the ORM scope, but the test harness which seeks to control the scope of the transaction externally does not expect a new transaction to start implicitly. Fixes: #4712 Change-Id: Ibc6c8d981cff31594a5d26dd5203fd9cfcea1c74
* Render parenthesis around sqlite expression defaultsBartlomiej Biernacki2019-02-011-5/+72
| | | | | | | | | | | | | | Fixed bug in SQLite DDL where using an expression as a server side default required that it be contained within parenthesis to be accepted by the sqlite parser. Pull request courtesy Bartlomiej Biernacki. Fixes: #4474 Closes: #4475 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/4475 Pull-request-sha: 0af3238c69c2610333cf62082c12047d45c31ce0 Change-Id: I888c69bfba5a5ab8ffa420f512557ac311a36b31 (cherry picked from commit f7ce37e9dd493d4b60b3156f08ef4c98fd63904d)
* Add deprecation warnings to all deprecated APIsMike Bayer2019-01-231-5/+5
| | | | | | | | | | | | | | | A large change throughout the library has ensured that all objects, parameters, and behaviors which have been noted as deprecated or legacy now emit ``DeprecationWarning`` warnings when invoked. As the Python 3 interpreter now defaults to displaying deprecation warnings, as well as that modern test suites based on tools like tox and pytest tend to display deprecation warnings, this change should make it easier to note what API features are obsolete. See the notes added to the changelog and migration notes for further details. Fixes: #4393 Change-Id: If0ea11a1fc24f9a8029352eeadfc49a7a54c0a1b
* Post black reformattingMike Bayer2019-01-061-43/+47
| | | | | | | | | | | | | 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-656/+957
| | | | | | | | | | | | | | 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
* Implement SQLite ON CONFLICT for constraintsDenis Kataev2018-11-071-1/+135
| | | | | | | | | | | Implemented the SQLite ``ON CONFLICT`` clause as understood at the DDL level, e.g. for primary key, unique, and CHECK constraints as well as specified on a :class:`.Column` to satisfy inline primary key and NOT NULL. Pull request courtesy Denis Kataev. Fixes: #4360 Change-Id: I4cd4bafa8fca41e3101c87dbbfe169741bbda3f4 Pull-request: https://github.com/zzzeek/sqlalchemy/pull/431
* Fix quoting schemas in _get_table_sql for the SQLite backendPhillip Cloud2018-07-181-0/+25
| | | | | | | | | Fixed issue where the "schema" name used for a SQLite database within table reflection would not quote the schema name correctly. Pull request courtesy Phillip Cloud. Change-Id: I2770788c1f094a7743209250ec26b5ef5fb2d9e8 Pull-request: https://github.com/zzzeek/sqlalchemy/pull/463
* Sqlite jsonIlja Everilä2018-07-101-0/+62
| | | | | | | | | | | Added support for SQLite's json functionality via the new SQLite implementation for :class:`.sqltypes.JSON`, :class:`.sqlite.JSON`. The name used for the type is ``JSON``, following an example found at SQLite's own documentation. Pull request courtesy Ilja Everilä. Fixes: #3850 Change-Id: I3d2714fb8655343a99d13dc751b16b93d05d7dda Pull-request: https://github.com/zzzeek/sqlalchemy/pull/434
* fix TypeReflectionTest for sqlite 3.24Nils Philippsen2018-06-251-1/+1
| | | | | | | | | Fixed issue in test suite where SQLite 3.24 added a new reserved word that conflicted with a usage in TypeReflectionTest. Pull request courtesy Nils Philippsen. Change-Id: I396562cecb5ca774f29e9234845bcc6a399fc5cb Pull-request: https://github.com/zzzeek/sqlalchemy/pull/452
* Make all tests to be PEP8 compliantKhairi Hafsham2017-02-071-9/+10
| | | | | | | | 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-3/+3
| | | | | | | | | | | 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
* Change autoincrement compileerror to a warningMike Bayer2016-10-071-15/+28
| | | | | | | | Users are complaining that IntegrityError is no longer raised. Change-Id: I0855d5b7a98d4338f0910501b6e6d404ba33634d Fixes: #3216
* Add IS (NOT) DISTINCT FROM operatorsSebastian Bank2016-06-061-0/+11
| | | | | | | | | | | 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
* - further adjustment to accomodate for the "ON" in "NO ACTION"Mike Bayer2016-06-031-2/+10
| | | | Change-Id: I734e4aec3701d7cf17813b561a1418cfeff1d473
* Ensure "options" present for unnamed / unlocatable FKMike Bayer2016-06-031-11/+43
| | | | | | | Also ensure the regular expression and subsequent matching is case insensitive, add more tests Change-Id: Ie4aa971dcbffca94e78965e22982478eccbf8597
* Reflect ON DELETE and ON UPDATE for SQLite foreign keysMichal Petrucha2016-06-021-0/+37
| | | | | | Co-authored-by: Mike Bayer <mike_mp@zzzcomputing.com> Change-Id: Icd77ddbf851b1950f767022d67c8142b1b3c50f3 Pull-request: https://github.com/zzzeek/sqlalchemy/pull/244
* Implemented CHECK constraint reflection for SQLite and PostgreSQLAlex Grönholm2016-06-011-0/+15
| | | | | | Co-Authored-By: Mike Bayer <mike_mp@zzzcomputing.com> Change-Id: Ie6cf2d2958d1c567324db9e08fef2d3186e97350 Pull-request: https://bitbucket.org/zzzeek/sqlalchemy/pull-requests/80
* sqlite: reflect primary key constraint names, fixes #3629Diana Clarke2016-01-271-3/+34
|
* - The system by which a :class:`.Column` considers itself to be anMike Bayer2015-10-071-3/+37
| | | | | | | | | | | | | | | | | "auto increment" column has been changed, such that autoincrement is no longer implicitly enabled for a :class:`.Table` that has a composite primary key. In order to accommodate being able to enable autoincrement for a composite PK member column while at the same time maintaining SQLAlchemy's long standing behavior of enabling implicit autoincrement for a single integer primary key, a third state has been added to the :paramref:`.Column.autoincrement` parameter ``"auto"``, which is now the default. fixes #3216 - The MySQL dialect no longer generates an extra "KEY" directive when generating CREATE TABLE DDL for a table using InnoDB with a composite primary key with AUTO_INCREMENT on a column that isn't the first column; to overcome InnoDB's limitation here, the PRIMARY KEY constraint is now generated with the AUTO_INCREMENT column placed first in the list of columns.
* - limit the search for schemas to not include "temp", which is sort of an ↵Mike Bayer2015-09-281-23/+17
| | | | | | | | | | implicit schema - repair the CREATE INDEX ddl for schemas - update provisioning to include support for setting up ATTACH DATABASE up front for the test_schema; enable "schemas" testing for SQLite - changelog / migration notes for new SQLite schema support - include the "schema" as the "remote_schema" when we reflect SQLite FKs
* Support get_schema_names for SQLitepr/198Brian Van Klaveren2015-09-091-0/+5
| | | Should return "main" and the names of attached databases.
* Test for partial index support in sqlite dialects.Kai Groner2015-01-261-1/+22
|
* - rework sqlite FK and unique constraint system to combine both PRAGMAMike Bayer2014-12-131-123/+291
| | | | | | and regexp parsing of SQL in order to form a complete picture of constraints + their names. fixes #3244 fixes #3261 - factor various PRAGMA work to be centralized into one call
* - add test_get_unnamed_unique_constraints to SQLite reflection testsJon Nelson2014-12-131-0/+18
|
* - The SQLite dialect, when using the :class:`.sqlite.DATE`,Mike Bayer2014-12-051-0/+57
| | | | | | | | | | | | :class:`.sqlite.TIME`, or :class:`.sqlite.DATETIME` types, and given a ``storage_format`` that only renders numbers, will render the types in DDL as ``DATE_CHAR``, ``TIME_CHAR``, and ``DATETIME_CHAR``, so that despite the lack of alpha characters in the values, the column will still deliver the "text affinity". Normally this is not needed, as the textual values within the default storage formats already imply text. fixes #3257
* - pep8Mike Bayer2014-12-051-191/+232
|
* - rework tests for attached databases into individual tests,Mike Bayer2014-09-291-36/+102
| | | | | | | | | | | | | test both memory and file-based - When selecting from a UNION using an attached database file, the pysqlite driver reports column names in cursor.description as 'dbname.tablename.colname', instead of 'tablename.colname' as it normally does for a UNION (note that it's supposed to just be 'colname' for both, but we work around it). The column translation logic here has been adjusted to retrieve the rightmost token, rather than the second token, so it works in both cases. Workaround courtesy Tony Roberts. fixes #3211
* Merge branch 'sqlite-temp-table-reflection' of ↵Mike Bayer2014-09-171-0/+18
|\ | | | | | | https://bitbucket.org/jerdfelt/sqlalchemy/branch/sqlite-temp-table-reflection into pr31
| * Handle sqlite get_unique_constraints() call for temporary tablesJohannes Erdfelt2014-09-171-0/+18
| | | | | | | | | | | | | | The sqlite get_unique_constraints() implementation did not do a union against the sqlite_temp_master table like other code does. This could result in an exception being raised if get_unique_constraints() was called against a temporary table.
* | - Added :meth:`.Inspector.get_temp_table_names` andMike Bayer2014-09-171-17/+0
|/ | | | | | | | | | | | :meth:`.Inspector.get_temp_view_names`; currently, only the SQLite dialect supports these methods. The return of temporary table and view names has been **removed** from SQLite's version of :meth:`.Inspector.get_table_names` and :meth:`.Inspector.get_view_names`; other database backends cannot support this information (such as MySQL), and the scope of operation is different in that the tables can be local to a session and typically aren't supported in remote schemas. fixes #3204
* - add tests for the savepoint recipeMike Bayer2014-08-091-0/+78
|
* - Fixed a few errant ``u''`` strings that would prevent tests from passingMike Bayer2014-03-221-2/+2
| | | | in Py3.2. Patch courtesy Arfrever Frehtes Taifersar Arahesis. fixes #2980
View Lorry Controller Status