summaryrefslogtreecommitdiff
path: root/lib/sqlalchemy/dialects/mssql
Commit message (Collapse)AuthorAgeFilesLines
...
* Merge "Support multiple dotted sections in mssql schema names"mike bayer2020-06-011-9/+35
|\
| * Support multiple dotted sections in mssql schema namesMike Bayer2020-06-011-9/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Refined the logic used by the SQL Server dialect to interpret multi-part schema names that contain many dots, to not actually lose any dots if the name does not have bracking or quoting used, and additionally to support a "dbname" token that has many parts including that it may have multiple, independently-bracketed sections. This fix addresses #5364 to some degree but probably does not resolve it fully. References: #5364 Fixes: #5366 Change-Id: I460cd74ce443efb35fb63b6864f00c6d81422688
* | Merge "Add support for "real" sequences in mssql"mike bayer2020-06-012-40/+97
|\ \
| * | Add support for "real" sequences in mssqlGord Thompson2020-05-292-40/+97
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Fix is_disconnect false positive for mssql+pyodbcGord Thompson2020-06-011-3/+3
|/ | | | | | | | | | Fixed an issue where the ``is_disconnect`` function in the SQL Server pyodbc dialect was incorrectly reporting the disconnect state when the exception messsage had a substring that matched a SQL Server ODBC error code. Fixes: #5359 Change-Id: I450c6818405a20f4daee20d58fce2d5ecb33e17f
* callcount reductions and refinement for cached queriesMike Bayer2020-05-281-10/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit includes that we've removed the "_orm_query" attribute from compile state as well as query context. The attribute created reference cycles and also added method call overhead. As part of this change, the interface for ORMExecuteState changes a bit, as well as the interface for the horizontal sharding extension which now deprecates the "query_chooser" callable in favor of "execute_chooser", which receives the contextual object. This will also work more nicely when we implement the new execution path for bulk updates and deletes. Pre-merge execution options for statement, connection, arguments all up front in Connection. that way they can be passed to the before_execute / after_execute events, and the ExecutionContext doesn't have to merge as second time. Core execute is pretty close to 1.3 now. baked wasn't using the new one()/first()/one_or_none() methods, fixed that. Convert non-buffered cursor strategy to be a stateless singleton. inline all the paths by which the strategy gets chosen, oracle and SQL Server dialects make use of the already-invoked post_exec() hook to establish the alternate strategies, and this is actually much nicer than it was before. Add caching to mapper instance processor for getters. Identified a reference cycle per query that was showing up as a lot of gc cleanup, fixed that. After all that, performance not budging much. Even test_baked_query now runs with significantly fewer function calls than 1.3, still 40% slower. Basically something about the new patterns just makes this slower and while I've walked a whole bunch of them back, it hardly makes a dent. that said, the performance issues are relatively small, in the 20-40% time increase range, and the new caching feature does provide for regular ORM and Core queries that are cached, and they are faster than non-cached. Change-Id: I7b0b0d8ca550c05f79e82f75cd8eff0bbfade053
* Convert execution to move through SessionMike Bayer2020-05-251-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch replaces the ORM execution flow with a single pathway through Session.execute() for all queries, including Core and ORM. Currently included is full support for ORM Query, Query.from_statement(), select(), as well as the baked query and horizontal shard systems. Initial changes have also been made to the dogpile caching example, which like baked query makes use of a new ORM-specific execution hook that replaces the use of both QueryEvents.before_compile() as well as Query._execute_and_instances() as the central ORM interception hooks. select() and Query() constructs alike can be passed to Session.execute() where they will return ORM results in a Results object. This API is currently used internally by Query. Full support for Session.execute()->results to behave in a fully 2.0 fashion will be in later changesets. bulk update/delete with ORM support will also be delivered via the update() and delete() constructs, however these have not yet been adapted to the new system and may follow in a subsequent update. Performance is also beginning to lag as of this commit and some previous ones. It is hoped that a few central functions such as the coercions functions can be rewritten in C to re-gain performance. Additionally, query caching is now available and some subsequent patches will attempt to cache more of the per-execution work from the ORM layer, e.g. column getters and adapters. This patch also contains initial "turn on" of the caching system enginewide via the query_cache_size parameter to create_engine(). Still defaulting at zero for "no caching". The caching system still needs adjustments in order to gain adequate performance. Change-Id: I047a7ebb26aa85dc01f6789fac2bff561dcd555d
* Avoid proxy functions in row functionsFederico Caselli2020-05-231-1/+1
| | | | | | | | | | | This streamlines a bit for non-C implementations, however also adds and tests behavioral contracts that mappings should not allow integer or slice access and should behave like a Python mapping in that it raises KeyError for an integer and TypeError for a slice. Py3/Py2/C/noC :) References: #5340 Change-Id: Id3cef452dc8a526b8371c90c5ca2bbb240b25c26
* Merge "Add note re: pymssql not in CI"mike bayer2020-05-231-0/+5
|\
| * Add note re: pymssql not in CIGord Thompson2020-05-161-0/+5
| | | | | | | | Change-Id: I45f78131ffe1881a3965e8aa41bbc46da7d43a5b
* | Stop converting mssql datetime.time parameters to datetime.datetimeGord Thompson2020-05-231-1/+5
| | | | | | | | | | Fixes: #5339 Change-Id: Ida75422d8c3fdfc7adae68e547d88df49368a693
* | Add immutabledict C codeMike Bayer2020-05-231-1/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Start trying to convert fundamental objects to C as we now rely on a fairly small core of things, and 1.4 is having problems with complexity added being slower than the performance gains we are trying to build in. immutabledict here does seem to bench as twice as fast as the Python one, see below. However, it does not appear to be used prominently enough to make any dent in the performance tests. at the very least it may provide us some more lift-and-copy code for more C extensions. import timeit from sqlalchemy.util._collections import not_immutabledict, immutabledict def run(dict_cls): for i in range(1000000): d1 = dict_cls({"x": 5, "y": 4}) d2 = d1.union({"x": 17, "new key": "some other value"}, None) assert list(d2) == ["x", "y", "new key"] print( timeit.timeit( "run(d)", "from __main__ import run, not_immutabledict as d", number=1 ) ) print( timeit.timeit( "run(d)", "from __main__ import run, immutabledict as d", number=1 ) ) output: python: 1.8799766399897635 C code: 0.8880784640205093 Change-Id: I29e7104dc21dcc7cdf895bf274003af2e219bf6d
* Move supports_sane_rowcount_returning = False to dialect levelGord Thompson2020-05-111-0/+3
| | | | | Fixes: #5321 Change-Id: Id83e98e9013818424c133297a850746302633158
* Propose Result as immediate replacement for ResultProxyMike Bayer2020-05-011-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Deprecate unsupported dialects and dbapiFederico Caselli2020-04-293-91/+4
| | | | | | | | | | | | | | | | | - Deprecate dialects firebird and sybase. - Deprecate DBAPI - mxODBC for mssql - oursql for mysql - pygresql and py-postgresql for postgresql - Removed adodbapi DBAPI for mssql Fixes: #5189 Change-Id: Id9025f4f4de7e97d65aacd0eb4b0c21beb9a67b5
* Merge "Fix regression when reflecting tables in MSSQL"mike bayer2020-04-221-12/+29
|\
| * Fix regression when reflecting tables in MSSQLFederico Caselli2020-04-221-12/+29
| | | | | | | | | | | | | | | | | | | | | | | | Fix a regression introduced by the reflection of computed column in MSSQL when using SQL server versions before 2012, which does not support the ``concat`` function and when using the legacy TDS version 4.2. The dialect will try to detect the protocol version of first connect and run in compatibility mode if it cannot detect it. Fixes: #5255 Fixes: #5271 Change-Id: I7b33f7889ac0784cd8ae5385cbd50bc8c862398a
* | Fix typo in pymssql documentation; minor clarificationGord Thompson2020-04-201-2/+3
|/ | | | Change-Id: I4aaf0627d2f1ccae82c2eb41db9ec219d73ce4ea
* Merge "Deprecate ``DISTINCT ON`` when not targeting PostgreSQL"mike bayer2020-04-201-9/+3
|\
| * Deprecate ``DISTINCT ON`` when not targeting PostgreSQLFederico Caselli2020-04-201-9/+3
| | | | | | | | | | | | | | | | | | Deprecate usage of ``DISTINCT ON`` in dialect other than PostgreSQL. Previously this was silently ignored. Deprecate old usage of string distinct in MySQL dialect Fixes: #4002 Change-Id: I38fc64aef75e77748083c11d388ec831f161c9c9
* | Update pymssql information for mssql dialectGord Thompson2020-04-201-5/+18
|/ | | | Change-Id: I94cf63299a094b53e7078b282311f7d0faa256a6
* Create initial 2.0 engine implementationMike Bayer2020-04-161-13/+19
| | | | | | | | | | | | | | | | | | | Implemented the SQLAlchemy 2 :func:`.future.create_engine` function which is used for forwards compatibility with SQLAlchemy 2. This engine features always-transactional behavior with autobegin. Allow execution options per statement execution. This includes that the before_execute() and after_execute() events now accept an additional dictionary with these options, empty if not passed; a legacy event decorator is added for backwards compatibility which now also emits a deprecation warning. Add some basic tests for execution, transactions, and the new result object. Build out on a new testing fixture that swaps in the future engine completely to start with. Change-Id: I70e7338bb3f0ce22d2f702537d94bb249bd9fb0a Fixes: #4644
* Set up absolute references for create_engine and relatedMike Bayer2020-04-142-8/+10
| | | | | | | includes more replacements for create_engine(), Connection, disambiguation of Result from future/baked Change-Id: Icb60a79ee7a6c45ea9056c211ffd1be110da3b5e
* Run search and replace of symbolic module namesMike Bayer2020-04-141-28/+40
| | | | | | | | Replaces a wide array of Sphinx-relative doc references with an abbreviated absolute form now supported by zzzeeksphinx. Change-Id: I94bffcc3f37885ffdde6238767224296339698a2
* Enable zzzeeksphinx module prefixesMike Bayer2020-04-141-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | zzzeeksphinx 1.1.2 in git can now convert short prefix names in a configured lookup to fully qualified module names, so that we can have succinct and portable pyrefs that still resolve absolutely. It also includes a formatter that will format all pyrefs in a fully consistent way regardless of the package path, by unconditionally removing all package tokens but always leaving class names in place including for methods, which means we no longer have to deal with tildes in pyrefs. The most immediate goal of the absolute prefixes is that we have lots of "ambiguous" names that appear in muliple places, like select(), ARRAY, ENUM etc. With the incoming future packages there is going to be lots of name overlap so it is necessary that all names eventually use absolute package paths when Sphinx receives them. In multiple stages, pyrefs will be converted using the zzzeeksphinx tools/fix_xrefs.py tool so that doclinks can be made absolute using symbolic prefixes. For this review, the actual search and replace of symbols is not performed, instead some general cleanup to prepare the docs as well as a lookup file used by the tool to do the conversion. this relatively small patch will be backported with appropriate changes to 1.3, 1.2, 1.1 and the tool can then be run on each branch individually. We are shooting for almost no warnings at all for master (still a handful I can't figure out which don't seem to have any impact) , very few for 1.3, and for 1.2 / 1.1 we hope for a significant reduction in warnings. Overall for all versions pyrefs should always point to the correct target, if they are in fact hyperlinked. it's better for a ref to go nowhere and be plain text than go to the wrong thing. Right now, hundreds of API links are pointing to the wrong thing as they are ambiguous names such as refresh(), insert(), update(), select(), join(), JSON etc. and Sphinx sends these all to essesntially random destinations among as many as five or six possible choices per symbol. A shorthand system that allows us to use absolute refs without having to type out a full blown absoulte module is the only way this is going to work, and we should ultimately seek to abandon any use of prefix dot for lookups. Everything should be on an underscore token so at the very least the module spaces can be reorganized without having to search and replace the entire documentation every time. Change-Id: I484a7329034af275fcdb322b62b6255dfeea9151
* Remove code deprecated before version 1.1Federico Caselli2020-04-091-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Remove deprecated method ``get_primary_keys` in the :class:`.Dialect` and :class:`.Inspector` classes. - Remove deprecated event ``dbapi_error`` and the method ``ConnectionEvents.dbapi_error`. - Remove support for deprecated engine URLs of the form ``postgres://``. - Remove deprecated dialect ``mysql+gaerdbms``. - Remove deprecated parameter ``quoting`` from :class:`.mysql.ENUM` and :class:`.mysql.SET` in the ``mysql`` dialect. - Remove deprecated function ``comparable_property``. and function ``comparable_using`` in the declarative extension. - Remove deprecated function ``compile_mappers``. - Remove deprecated method ``collection.linker``. - Remove deprecated method ``Session.prune`` and parameter ``Session.weak_identity_map``. This change also removes the class ``StrongInstanceDict``. - Remove deprecated parameter ``mapper.order_by``. - Remove deprecated parameter ``Session._enable_transaction_accounting`. - Remove deprecated parameter ``Session.is_modified.passive``. - Remove deprecated class ``Binary``. Please use :class:`.LargeBinary`. - Remove deprecated methods ``Compiled.compile``, ``ClauseElement.__and__`` and ``ClauseElement.__or__`` and attribute ``Over.func``. - Remove deprecated ``FromClause.count`` method. - Remove deprecated parameter ``Table.useexisting``. - Remove deprecated parameters ``text.bindparams`` and ``text.typemap``. - Remove boolean support for the ``passive`` parameter in ``get_history``. - Remove deprecated ``adapt_operator`` in ``UserDefinedType.Comparator``. Fixes: #4643 Change-Id: Idcd390c77bf7b0e9957907716993bdaa3f1a1763
* Broaden is[not]_distinct_from supportGord Thompson2020-04-021-0/+12
| | | | | | | Added support for .is[not]_distinct_from to SQL Server, MySQL, and Oracle. Fixes: #5137 Change-Id: I3b4d3b199821a55687f83c9a5b63a95d07a64cd5
* Correct ambiguous func / class linksMike Bayer2020-03-251-2/+2
| | | | | | | | | :func:`.sql.expression.select`, :func:`.sql.expression.insert` and :class:`.sql.expression.Insert` were hitting many ambiguous symbol errors, due to future.select, as well as the PG/MySQL variants of Insert. Change-Id: Iac862bfc172a7f7f0cbba5353a83dc203bed376c
* Deprecate plain string in execute and introduce `exec_driver_sql`Federico Caselli2020-03-214-19/+19
| | | | | | | | | | | | | | | 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
* Support inspection of computed columnFederico Caselli2020-03-152-21/+54
| | | | | | | | | | | | | | | | | | | Added support for reflection of "computed" columns, which are now returned as part of the structure returned by :meth:`.Inspector.get_columns`. When reflecting full :class:`.Table` objects, computed columns will be represented using the :class:`.Computed` construct. Also improve the documentation in :meth:`Inspector.get_columns`, correctly listing all the returned keys. Fixes: #5063 Fixes: #4051 Closes: #5064 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/5064 Pull-request-sha: ba00fc321ce468f8885aad23b3dd33c789e50fbe Change-Id: I789986554fc8ac7f084270474d0b2c12046b1cc2
* Fix tests failing for SQLite file databases; repair provisioningGord Thompson2020-03-131-5/+1
| | | | | | | | | | | | | | | | | | | | | | 1. ensure provision.py loads dialect implementations when running reap_dbs.py. Reapers haven't been working since 598f2f7e557073f29563d4d567f43931fc03013f . 2. add some exclusion rules to allow the sqlite_file target to work; add to tox. 3. add reap dbs target for SQLite, repair SQLite drop_db routine which also wasn't doing the right thing for memory databases etc. 4. Fix logging in provision files, as the main provision logger is the one that's enabled by reap_dbs and maybe others, have all the provision files use the provision logger. Fixes: #5180 Fixes: #5168 Change-Id: Ibc1b0106394d20f5bcf847f37b09d185f26ac9b5
* Decouple compiler state from DML objects; make cacheableMike Bayer2020-03-061-19/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Targeting select / insert / update / delete, the goal is to minimize overhead of construction and generative methods so that only the raw arguments passed are handled. An interim stage that converts the raw state into more compiler-ready state is added, which is analogous to the ORM QueryContext which will also be rolled in to be a similar concept, as is currently being prototyped in I19e05b3424b07114cce6c439b05198ac47f7ac10. the ORM update/delete BulkUD concept is also going to be rolled onto this idea. So while the compiler-ready state object, here called DMLState, looks a little thin, it's the base of a bigger pattern that will allow for ORM functionality to embed itself directly into the compiler, execution context, and result set objects. This change targets the DML objects, primarily focused on the values() method which is the most complex process. The work done by values() is minimized as much as possible while still being able to create a cache key. Additional computation is then offloaded to a new object ValuesState that is handled by the compiler. Architecturally, a big change here is that insert.values() and update.values() will generate BindParameter objects for the values now, which are then carefully received by crud.py so that they generate the expected names. This is so that the values() portion of these constructs is cacheable. for the "multi-values" version of Insert, this is all skipped and the plan right now is that a multi-values insert is not worth caching (can always be revisited). Using the coercions system in values() also gets us nicer validation for free, we can remove the NotAClauseElement thing from schema, and we also now require scalar_subquery() is called for an insert/update that uses a SELECT as a column value, 1.x deprecation path is added. The traversal system is then applied to the DML objects including tests so that they have traversal, cloning, and cache key support. cloning is not a use case for DML however having it present allows better validation of the structure within the tests. Special per-dialect DML is explicitly not cacheable at the moment, more as a proof of concept that third party DML constructs can exist as gracefully not-cacheable rather than producing an incomplete cache key. A few selected performance improvements have been added as well, simplifying the immutabledict.union() method and adding a new SQLCompiler function that can generate delimeter-separated clauses like WHERE and ORDER BY without having to build a ClauseList object at all. The use of ClauseList will be removed from Select in an upcoming commit. Overall, ClaustList is unnecessary for internal use and only adds overhead to statement construction and will likely be removed as much as possible except for explcit use of conjunctions like and_() and or_(). Change-Id: I408e0b8be91fddd77cf279da97f55020871f75a9
* Don't import provision.py unconditionallyMike Bayer2020-03-031-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | Removed the imports for provision.py from each dialect and instead added a call in the central provision.py to a new dialect level method load_provisioning(). The provisioning registry works in the same way, so an existing dialect that is using the provision.py system right now by importing it as part of the package will still continue to function. However, to avoid pulling in the testing package when the dialect is used in a non-testing context, the new hook may be used. Also removed a module-level dependency of the testing framework on the orm package. Revised an internal change to the test system added as a result of :ticket:`5085` where a testing-related module per dialect would be loaded unconditionally upon making use of that dialect, pulling in SQLAlchemy's testing framework as well as the ORM into the module import space. This would only impact initial startup time and memory to a modest extent, however it's best that these additional modules aren't reverse-dependent on straight Core usage. Fixes: #5180 Change-Id: I6355601da5f6f44d85a2bbc3acb5928559942b9c
* Result initial introductionMike Bayer2020-02-211-19/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Merge "Replace engine.execute w/ context manager (step1)"mike bayer2020-02-191-1/+2
|\
| * Replace engine.execute w/ context manager (step1)Gord Thompson2020-02-171-1/+2
| | | | | | | | | | | | | | | | | | 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
* | Merge "Create initial future package, RemovedIn20Warning"mike bayer2020-02-171-1/+1
|\ \ | |/ |/|
| * Create initial future package, RemovedIn20WarningMike Bayer2020-02-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reorganization of Select() is the first major element of the 2.0 restructuring. In order to start this we need to first create the new Select constructor and apply legacy elements to the old one. This in turn necessitates starting up the RemovedIn20Warning concept which itself need to refer to "sqlalchemy.future", so begin to establish this basic framework. Additionally, update the DML constructors with the newer no-keyword style. Remove the use of the "pending deprecation" and fix Query.add_column() deprecation which was not acting as deprecated. Fixes: #4845 Fixes: #4648 Change-Id: I0c7a22b2841a985e1c379a0bb6c94089aae6264c
* | Document new LIMIT/OFFSET support; support subquery ORDER BYMike Bayer2020-02-131-8/+21
| | | | | | | | | | | | | | | | | | An adjustment to the original commit for the fix to #5084 in ab1799a2a1951fe8f188b6395fde04a233a3ac0d, correctly rendering ORDER BY for subqueries with the new syntax. Fixes: #5084 Change-Id: I5ab5c1887c5a10f0a5eed1e9aae1f5994c28d88e
* | Fix handling of None as parameter for a datetimeoffset columnGord Thompson2020-02-101-4/+15
| | | | | | | | | | | | | | | | | | | | | | | | Fixed issue where the :class:`.mssql.DATETIMEOFFSET` type would not accommodate for the ``None`` value, introduced as part of the series of fixes for this type first introduced in :ticket:`4983`, :ticket:`5045`. Additionally, added support for passing a backend-specific date formatted string through this type, as is typically allowed for date/time types on most other DBAPIs. Fixes: #5132 Change-Id: Iab05d67382e0f550474d50e0c3c1c888521b678a
* | Fixes for public_factory and mysql/pg dml functionsMike Bayer2020-02-081-14/+19
|/ | | | | | | | | | | | | | | | * ensure that the location indicated by public_factory is importable * adjust all of sqlalchemy.sql.expression locations to be correct * support the case where a public_factory is against a function that has another public_factory already, and already replaced the __init__ on the target class * Use mysql.insert(), postgresql.insert(), don't include .dml in the class path. Change-Id: Iac285289455d8d7102349df3814f7cedc758e639
* MSSQL 2014 OFFSET/FETCH syntax supportElkin2020-02-071-3/+45
| | | | | | | | | | | | | | SQL Server OFFSET and FETCH keywords are now used for limit/offset, rather than using a window function, for SQL Server versions 11 and higher. TOP is still used for a query that features only LIMIT. Pull request courtesy Elkin. Fixes: #5084 Closes: #5125 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/5125 Pull-request-sha: a45b7f73090d2053e3a7020d4e3d7fabb0c5627d Change-Id: Id6a01ba30caac87d7d3d92c3903cdfd77fbcee5e
* Refactor test provisioning to dialect-level filesGord Thompson2020-01-262-0/+85
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes: #5085 <!-- Provide a general summary of your proposed changes in the Title field above --> Move dialect-specific provisioning code to dialect-level copies of provision.py. <!-- go over following points. check them with an `x` if they do apply, (they turn into clickable checkboxes once the PR is submitted, so no need to do everything at once) --> This pull request is: - [ ] A documentation / typographical error fix - Good to go, no issue or tests are needed - [x] A short code fix - please include the issue number, and create an issue if none exists, which must include a complete example of the issue. one line code fixes without an issue and demonstration will not be accepted. - Please include: `Fixes: #<issue number>` in the commit message - please include tests. one line code fixes without tests will not be accepted. - [ ] A new feature implementation - please include the issue number, and create an issue if none exists, which must include a complete example of how the feature would look. - Please include: `Fixes: #<issue number>` in the commit message - please include tests. **Have a nice day!** Closes: #5092 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/5092 Pull-request-sha: 25b9b7a9800549fb823576af8674e8d33ff4b2c1 Change-Id: Ie0b4a69aa472a60bdbd825e04c8595382bcc98e1
* Remove jython code, remove all jython / pypy symbolsMike Bayer2020-01-172-72/+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
* happy new yearMike Bayer2020-01-018-8/+8
| | | | Change-Id: I08440dc25e40ea1ccea1778f6ee9e28a00808235
* Fix DATETIMEOFFSET formatting to preserve fractional seconds.Gord Thompson2019-12-311-2/+2
| | | | | | | | | | | | | Fixed issue where a timezone-aware ``datetime`` value being converted to string for use as a parameter value of a :class:`.mssql.DATETIMEOFFSET` column was omitting the fractional seconds. Fixes: #5045 Closes: #5046 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/5046 Pull-request-sha: 99dc7b23f69b7b068795a02d20b88bf352c7dcd7 Change-Id: I971629466fe0675536bbdf55693f0c1821dfb3cc
* Use expanding IN for all literal value IN expressionsMike Bayer2019-12-221-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | 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 note re: pyodbc keywords in lowercase.Gord Thompson2019-12-031-0/+2
|
* Add DATETIMEOFFSET support for mssql+pyodbcGord Thompson2019-11-291-0/+48
| | | | | | | | | | | | | | | Repaired support for the :class:`.mssql.DATETIMEOFFSET` datatype on PyODBC, by adding PyODBC-level result handlers as it does not include native support for this datatype. This includes usage of the Python 3 "timezone" tzinfo subclass in order to set up a timezone, which on Python 2 makes use of a minimal backport of "timezone" in sqlalchemy.util. Fixes: #4983 Closes: #4986 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/4986 Pull-request-sha: e3a5a8dda01c7580dc93271092c4f9beaac4be11 Change-Id: Ia4c7c0d1971c6c0492515bd5fa0b1799f07fee1c
* Base mssql.DATETIMEOFFSET on DateTimeMike Bayer2019-11-131-3/+3
| | | | | | | | | | | | | | Fixed the base class of the :class:`.mssql.DATETIMEOFFSET` datatype to be based on the :class:`.DateTime` class hierarchy, as this is a datetime-holding datatype. Note however that at the moment the pyodbc driver has only limited support for this datatype and will not work with all ODBC drivers. References: https://github.com/mkleehammer/pyodbc/issues/134 Fixes: #4980 Change-Id: I946cf22642eea4beee2a605d91218c6fd817740c
View Lorry Controller Status