summaryrefslogtreecommitdiff
path: root/lib/sqlalchemy/testing/suite/test_insert.py
Commit message (Collapse)AuthorAgeFilesLines
* add bind casts for BYTEA on asyncpgMike Bayer2023-05-041-0/+2
| | | | | | | | | | | Fixed another regression due to the "insertmanyvalues" change in 2.0.10 as part of :ticket:`9618`, in a similar way as regression :ticket:`9701`, where :class:`.LargeBinary` datatypes also need additional casts on when using the asyncpg driver specifically in order to work with the new bulk INSERT format. Fixes: #9739 Change-Id: I57370d269ea757f263c1f3a16c324ceae76fd4e8
* ensure correct cast for floats vs. numeric; other fixesMike Bayer2023-04-261-0/+111
| | | | | | | | | | | | | | | | | Fixed regression caused by the fix for :ticket:`9618` where floating point values would lose precision being inserted in bulk, using either the psycopg2 or psycopg drivers. Implemented the :class:`_sqltypes.Double` type for SQL Server, having it resolve to ``REAL``, or :class:`_mssql.REAL`, at DDL rendering time. Fixed issue in Oracle dialects where ``Decimal`` returning types such as :class:`_sqltypes.Numeric` would return floating point values, rather than ``Decimal`` objects, when these columns were used in the :meth:`_dml.Insert.returning` clause to return INSERTed values. Fixes: #9701 Change-Id: I8865496a6ccac6d44c19d0ca2a642b63c6172da9
* implement batched INSERT..VALUES () () for executemanyMike Bayer2022-09-241-0/+21
| | | | | | | | | | | | | | | | | | | | the feature is enabled for all built in backends when RETURNING is used, except for Oracle that doesn't need it, and on psycopg2 and mssql+pyodbc it is used for all INSERT statements, not just those that use RETURNING. third party dialects would need to opt in to the new feature by setting use_insertmanyvalues to True. Also adds dialect-level guards against using returning with executemany where we dont have an implementation to suit it. execute single w/ returning still defers to the server without us checking. Fixes: #6047 Fixes: #7907 Change-Id: I3936d3c00003f02e322f2e43fb949d0e6e568304
* Generalize RETURNING and suppor for MariaDB / SQLiteDaniel Black2022-06-021-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As almost every dialect supports RETURNING now, RETURNING is also made more of a default assumption. * the default compiler generates a RETURNING clause now when specified; CompileError is no longer raised. * The dialect-level implicit_returning parameter now has no effect. It's not fully clear if there are real world cases relying on the dialect-level parameter, so we will see once 2.0 is released. ORM-level RETURNING can be disabled at the table level, and perhaps "implicit returning" should become an ORM-level option at some point as that's where it applies. * Altered ORM update() / delete() to respect table-level implicit returning for fetch. * Since MariaDB doesnt support UPDATE returning, "full_returning" is now split into insert_returning, update_returning, delete_returning * Crazy new thing. Dialects that have *both* cursor.lastrowid *and* returning. so now we can pick between them for SQLite and mariadb. so, we are trying to keep it on .lastrowid for simple inserts with an autoincrement column, this helps with some edge case test scenarios and i bet .lastrowid is faster anyway. any return_defaults() / multiparams etc then we use returning * SQLite decided they dont want to return rows that match in ON CONFLICT. this is flat out wrong, but for now we need to work with it. Fixes: #6195 Fixes: #7011 Closes: #7047 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/7047 Pull-request-sha: d25d5ea3abe094f282c53c7dd87f5f53a9e85248 Co-authored-by: Mike Bayer <mike_mp@zzzcomputing.com> Change-Id: I9908ce0ff7bdc50bd5b27722081767c31c19a950
* inline mypy config; files ignoring type errors for the momentMike Bayer2022-04-281-0/+2
| | | | | | | | | | | | | | | | | | | to simplify pyproject.toml change the remaining files that aren't going to be typed on this first pass (unless of course someone wants to type some of these) to include # mypy: ignore-errors. for the moment, only a handful of ORM modules are to have more type checking implemented. It's important that ignore-errors is used and not "# type: ignore", as in the latter case, mypy doesn't even read the existing types in the file, which makes it impossible to type any files that refer to those modules at all. to simplify ongoing typing work use inline mypy config for remaining files that are "done" for now, indicating the level of type checking they currently have. Change-Id: I98669c1a305c2f0adba85d10b5425541f3fe9533
* Deprecate create_engine.implicit_returningjonathan vanasco2021-11-091-18/+6
| | | | | | | | | | | | | | | | | | | | | | | | The :paramref:`_sa.create_engine.implicit_returning` parameter is deprecated on the :func:`_sa.create_engine` function only; the parameter remains available on the :class:`_schema.Table` object. This parameter was originally intended to enable the "implicit returning" feature of SQLAlchemy when it was first developed and was not enabled by default. Under modern use, there's no reason this parameter should be disabled, and it has been observed to cause confusion as it degrades performance and makes it more difficult for the ORM to retrieve recently inserted server defaults. The parameter remains available on :class:`_schema.Table` to specifically suit database-level edge cases which make RETURNING infeasible, the sole example currently being SQL Server's limitation that INSERT RETURNING may not be used on a table that has INSERT triggers on it. Also removed from the Oracle dialect some logic that would upgrade an Oracle 8/8i server version to use implicit returning if the parameter were explictly passed; these versions of Oracle still support RETURNING so the feature is now enabled for all Oracle versions. Fixes: #6962 Change-Id: Ib338e300cd7c8026c3083043f645084a8211aed8
* Provide primary key values for data in tests that aren't about primary keys.Jim Fulton2021-05-241-0/+1
| | | | | | | | | | | | | | | (message written by Mike) some backends such as BigQuery have no autoincrement mechanism at all. while we would like to pursue a strategy where provisioning.py could provide for an in-Python sequence generator, at least remove the need for autoincrement in suite tests that don't need it. Fixes: #6469 Closes: #6504 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/6504 Pull-request-sha: c075014ef7de33e6eb3f389d24251ba184655e0b Change-Id: I98e237a38417b68c87d0201717205d7655b1f44e
* Support DEFAULT VALUES and VALUES(DEFAULT) individuallyMike Bayer2021-04-141-1/+14
| | | | | | | | | | | | | Fixed regression where the introduction of the INSERT syntax "INSERT... VALUES (DEFAULT)" was not supported on some backends that do however support "INSERT..DEFAULT VALUES", including SQLite. The two syntaxes are now each individually supported or non-supported for each dialect, for example MySQL supports "VALUES (DEFAULT)" but not "DEFAULT VALUES". Support for Oracle is still not enabled as there are unresolved issues in using RETURNING at the same time. Fixes: #6254 Change-Id: I47959bc826e3d9d2396ccfa290eb084841b02e77
* update execute() arg formats in modules and testsMike Bayer2021-01-151-9/+15
| | | | | | | | | | | | | continuing with producing a SQLAlchemy 1.4.0b2 that internally does not emit any of its own 2.0 deprecation warnings, migrate the *args and **kwargs passed to execute() methods that now must be a single list or dictionary. Alembic 1.5 is again waiting on this internal consistency to be present so that it can pass all tests with no 2.0 deprecation warnings. Change-Id: If6b792e57c8c5dff205419644ab68e631575a2fa
* upgrade to black 20.8b1Mike Bayer2020-09-281-2/+10
| | | | | | | 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
* Create a framework to allow all SQLALCHEMY_WARN_20 to passMike Bayer2020-09-161-2/+6
| | | | | | | | | | | | | | | | | | | | | As the test suite has widespread use of many patterns that are deprecated, enable SQLALCHEMY_WARN_20 globally for the test suite but then break the warnings filter out into a whole list of all the individual warnings we are looking for. this way individual changesets can target a specific class of warning, as many of these warnings will indivdidually affect dozens of files and potentially hundreds of lines of code. Many warnings are also resolved here as this patch started out that way. From this point forward there should be changesets that target a subset of the warnings at a time. For expediency, updates some migration 2.0 docs for ORM as well. Change-Id: I98b8defdf7c37b818b3824d02f7668e3f5f31c94
* Update select usage to use the new 1.4 formatFederico Caselli2020-09-081-13/+13
| | | | | | | | | | | | | | | | 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
* Default psycopg2 executemany mode to "values_only"Mike Bayer2020-06-251-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The psycopg2 dialect now defaults to using the very performant ``execute_values()`` psycopg2 extension for compiled INSERT statements, and also impements RETURNING support when this extension is used. This allows INSERT statements that even include an autoincremented SERIAL or IDENTITY value to run very fast while still being able to return the newly generated primary key values. The ORM will then integrate this new feature in a separate change. Implements RETURNING for insert with executemany Adds support to return_defaults() mode and inserted_primary_key to support mutiple INSERTed rows, via return_defauls_rows and inserted_primary_key_rows accessors. within default execution context, new cached compiler getters are used to fetch primary keys from rows inserted_primary_key now returns a plain tuple. this is not yet a row-like object however this can be added. Adds distinct "values_only" and "batch" modes, as "values" has a lot of benefits but "batch" breaks cursor.rowcount psycopg2 minimum version 2.7 so we can remove the large number of checks for very old versions of psycopg2 simplify tests to no longer distinguish between native and non-native json Fixes: #5401 Change-Id: Ic08fd3423d4c5d16ca50994460c0c234868bd61c
* Add support for "real" sequences in mssqlGord Thompson2020-05-291-2/+6
| | | | | | | | | | | | | | | | | Added support for "CREATE SEQUENCE" and full :class:`.Sequence` support for Microsoft SQL Server. This removes the deprecated feature of using :class:`.Sequence` objects to manipulate IDENTITY characteristics which should now be performed using ``mssql_identity_start`` and ``mssql_identity_increment`` as documented at :ref:`mssql_identity`. The change includes a new parameter :paramref:`.Sequence.data_type` to accommodate SQL Server's choice of datatype, which for that backend includes INTEGER and BIGINT. The default starting value for SQL Server's version of :class:`.Sequence` has been set at 1; this default is now emitted within the CREATE SEQUENCE DDL for all backends. Fixes: #4235 Fixes: #4633 Change-Id: I6aa55c441e8146c2f002e2e201a7f645e667b916
* Propose Result as immediate replacement for ResultProxyMike Bayer2020-05-011-2/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As progress is made on the _future.Result, including breaking it out such that DBAPI behaviors are local to specific implementations, it becomes apparent that the Result object is a functional superset of ResultProxy and that basic operations like fetchone(), fetchall(), and fetchmany() behave pretty much exactly the same way on the new object. Reorganize things so that ResultProxy is now referred to as LegacyCursorResult, which subclasses CursorResult that represents the DBAPI-cursor version of Result, making use of a multiple inheritance pattern so that the functionality of Result is also available in non-DBAPI contexts, as will be necessary for some ORM patterns. Additionally propose the composition system for Result that will form the basis for ORM-alternative result systems such as horizontal sharding and dogpile cache. As ORM results will soon be coming directly from instances of Result, these extensions will instead build their own ResultFetchStrategies that perform the special steps to create composed or cached result sets. Also considering at the moment not emitting deprecation warnings for fetchXYZ() methods; the immediate issue is Keystone tests are calling upon it, but as the implementations here are proving to be not in any kind of conflict with how Result works, there's not too much issue leaving them around and deprecating at some later point. References: #5087 References: #4395 Fixes: #4959 Change-Id: I8091919d45421e3f53029b8660427f844fee0228
* Clean up .execute calls in test_insert.pyGord Thompson2020-04-111-52/+48
| | | | Change-Id: I87e144d00577b53baab203c675caeaf8ad46cb5c
* Replace engine.execute w/ context manager (step1)Gord Thompson2020-02-171-4/+6
| | | | | | | | | First (baby) step at replacing engine.execute calls in test code with the new preferred way of executing. MSSQL was targeted because it was the easiest for me to test locally. Change-Id: Id2e02f0e39007cbfd28ca6a535115f53c6407015
* Remove jython code, remove all jython / pypy symbolsMike Bayer2020-01-171-4/+0
| | | | | | | | | | | | | | | | | | | | | | Removed all dialect code related to support for Jython and zxJDBC. Jython has not been supported by SQLAlchemy for many years and it is not expected that the current zxJDBC code is at all functional; for the moment it just takes up space and adds confusion by showing up in documentation. At the moment, it appears that Jython has achieved Python 2.7 support in its releases but not Python 3. If Jython were to be supported again, the form it should take is against the Python 3 version of Jython, and the various zxJDBC stubs for various backends should be implemented as a third party dialect. Additionally modernized logic that distinguishes between "cpython" and "pypy" to instead look at platform.python_distribution() which reliably tells us if we are cPython or not; all booleans which previously checked for pypy and sometimes jython are now converted to be "not cpython", this impacts the test suite for tests that are cPython centric. Fixes: #5094 Change-Id: I226cb55827f997daf6b4f4a755c18e7f4eb8d9ad
* Fix many spell glitchesLele Gaifax2019-01-251-1/+1
| | | | | | | | | | | | 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-8/+11
| | | | | | | | | | | | | 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-113/+108
| | | | | | | | | | | | | | 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
* Don't select lastrowid for inline=TrueMike Bayer2016-12-211-0/+50
| | | | | | | | | | | - Fixed bug where SQL Server dialects would attempt to select the last row identity for an INSERT from SELECT, failing in the case when the SELECT has no rows. For such a statement, the inline flag is set to True indicating no last primary key should be fetched. Change-Id: Ic40d56d9eadadc3024a4d71245f9eed4c420024a Fixes: #3876
* - The "auto close" for :class:`.ResultProxy` is now a "soft" close.Mike Bayer2015-03-171-3/+6
| | | | | | | | | | | 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
* add more order by hereMike Bayer2014-10-111-1/+1
|
* - change this literal so that the bound name doesn't have a numericMike Bayer2014-10-111-2/+2
| | | | name, this is sort of a bug for oracle
* - :meth:`.Insert.from_select` now includes Python and SQL-expressionMike Bayer2014-10-101-1/+36
| | | | | | | defaults if otherwise unspecified; the limitation where non- server column defaults aren't included in an INSERT FROM SELECT is now lifted and these expressions are rendered as constants into the SELECT statement.
* - apply pep8 formatting to sqlalchemy/sql, sqlalchemy/util, sqlalchemy/dialects,Brian Jarrett2014-07-201-38/+39
| | | | sqlalchemy/orm, sqlalchemy/event, sqlalchemy/testing
* - rename __multiple__ to __backend__, and apply __backend__ to a large ↵Mike Bayer2014-03-241-3/+3
| | | | | | number of tests. - move out logging tests from test_execute to test_logging
* - Support has been added for pytest to run tests. This runnerMike Bayer2014-03-031-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* - fix the insert from select test to use a non-autoinc tableMike Bayer2013-12-281-4/+8
|
* - repair some suite tests for firebirdMike Bayer2013-12-271-1/+15
|
* - assorted fixes raised by pypy 2.1beta2, but all of which are goodMike Bayer2013-08-011-2/+3
| | | | | | | | | | | | | | | ideas in general: - pypy2.1 w/ sqlite3 is the first DBAPI we're seeing returning unicode in cursor.description without being py3k. add a new on-connect check for this, if we get back a u"", just don't do description decoding, should be OK for now. - the set tests in test_collection were assuming the two sets would be ordered the same when it tested pop(), can't really assume that. - test_serializer gets worse and worse, pickle is just not really viable here, ding out pypy - pypy2.1b2 seems to allow cursor.lastrowid to work (or we changed something?) - pool._threadconns.current() is a weakref, it can be None - another one of those logging.handlers imports
* - use inline=True for the insert..select here so it works on oracleMike Bayer2013-07-121-2/+2
|
* - Added new method to the :func:`.insert` constructMike Bayer2013-07-051-0/+28
| | | | | | | | | | :meth:`.Insert.from_select`. Given a list of columns and a selectable, renders ``INSERT INTO (table) (columns) SELECT ..``. While this feature is highlighted as part of 0.9 it is also backported to 0.8.3. [ticket:722] - The :func:`.update`, :func:`.insert`, and :func:`.delete` constructs will now interpret ORM entities as FROM clauses to be operated upon, in the same way that select() already does. Also in 0.8.3.
* - add an event to testing so that other dialects can intercept ↵Mike Bayer2013-03-241-2/+2
| | | | | | "test_needs_autoincrement" - get the assumption of "1" for "first sequence item" to be dialect configured
* - fix exclusion hereMike Bayer2013-02-061-7/+3
| | | | - mysql doesn't reset table counter here so test differently
* - add an "empty_inserts" requirement target plus a suite testMike Bayer2013-02-061-0/+18
| | | | - add suite tests for basic explicit Sequence support, result-row column access (tests that name_normalize is set correctly among many other things)
* just a pep8 pass of lib/sqlalchemy/testing/Diana Clarke2012-11-191-3/+2
|
* - add back __engine_options__Mike Bayer2012-10-041-8/+38
| | | | | - break test_insert tests into explicitly get_lastrowid() vs. implicit_returning tests, fix up requirements to split them out
* - test updatesMike Bayer2012-10-041-1/+26
|
* mssql: - [bug] Fixed bug where reflection of primary key constraintMike Bayer2012-09-301-1/+1
| | | | | | | would double up columns if the same constraint/table existed in multiple schemas. - force returns_rows to False for inserts where we know rows shouldnt be returned; allows post_exec() to use the cursor without issue
* - more tests, move some tests out of test_reflection, test_queryMike Bayer2012-09-271-0/+111
View Lorry Controller Status