in mariadb 10.2. more mariadb fixes coming Change-Id: I6e3a94ae7340772663677b1082506adbb2d84a38
The operator precedence for all comparison operators such as LIKE, IS, IN, MATCH, equals, greater than, less than, etc. has all been merged into one level, so that expressions which make use of these against each other will produce parentheses between them. This suits the stated operator precedence of databases like Oracle, MySQL and others which place all of these operators as equal precedence, as well as Postgresql as of 9.5 which has also flattened its operator precendence. Co-authored-by: Mike Bayer <mike_mp@zzzcomputing.com> Fixes: #3999 Change-Id: I3f3d5124a64af0d376361cdf15a97e2e703be56f Pull-request: https://github.com/zzzeek/sqlalchemy/pull/367
tested using pycodestyle version 2.2.0 Fixes: #3885 Change-Id: I5df43adc3aefe318f9eeab72a078247a548ec566 Pull-request: https://github.com/zzzeek/sqlalchemy/pull/343
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
Options like uselist and backref can be determined from within _register_attribute based on parent_property given; move this logic inside so that individual strategies have less responsibility. Also don't require that _register_attribute consider the "strategy" itself at all; it would be better if we could no longer require that Joined/Subquery/etc loaders call upon the "lazy" strategy in order to initialize attribute instrumentation and this could be done more generically. Fixes long-standing bug where the "noload" relationship loading strategy would cause backrefs and/or back_populates options to be ignored. There is concern that some application that uses "noload" might be surprised at a back-populating attribute appearing suddenly, which may have side effects. However, "noload" itself must be extremely seldom used since as a strategy, it already disables loading, population of attributes is the only behavior that is even supported, so that this issue has existed for at least through 0.7 four years ago without ever being reported indicates extremely low use of this option. Change-Id: Icffb9c83ac5782b76ce882ed1df4361a1efbfba3 Fixes: #3845
count() here is misleading in that it not only counts from an arbitrary column in the table, it also does not make accommodations for DISTINCT, JOIN, etc. as the ORM-level function does. Core should not be attempting to provide a function like this. Change-Id: I9916fc51ef744389a92c54660ab08e9695b8afc2 Fixes: #3724
This is an old parameter no longer relevant to how SQLAlchemy works, once the Query object was introduced. By deprecating it we establish that we aren't supporting non-working use cases and that we encourage applications to move off of the use of this parameter. Fixes: #3394 Change-Id: I25b9a38142a1537bbcb27d3e8b66a8b265140072
"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.
primaryjoin that referred to the same "local" column multiple times in the "column that points to itself" style of self-referential join would not be substituted in all cases. The logic to determine substitutions here has been reworked to be more open-ended. fixes #3300
ultimately will populate a foreign key column in conflict with another, where the relationships are attempting to copy values from different source columns. This occurs in the case where composite foreign keys with overlapping columns are mapped to relationships that each refer to a different referenced column. A new documentation section illustrates the example as well as how to overcome the issue by specifying "foreign" columns specifically on a per-relationship basis. fixes #3230