See also
│ │ │RowProxy is no longer a “proxy”; is now called Row and behaves like an enhanced named tuple
│ │ │References: #4710
│ │ │ │ │ │ │ │ │ -[engine] [change] [performance] [py3k] ¶
Disabled the “unicode returns” check that runs on dialect startup when │ │ │ +
[engine] [performance] ¶
The pool “pre-ping” feature has been refined to not invoke for a DBAPI │ │ │ +connection that was just opened in the same checkout operation. pre ping │ │ │ +only applies to a DBAPI connection that’s been checked into the pool │ │ │ +and is being checked out again.
│ │ │ +References: #4524
│ │ │ + │ │ │ +[engine] [performance] [change] [py3k] ¶
Disabled the “unicode returns” check that runs on dialect startup when │ │ │ running under Python 3, which for many years has occurred in order to test │ │ │ the current DBAPI’s behavior for whether or not it returns Python Unicode │ │ │ or Py2K strings for the VARCHAR and NVARCHAR datatypes. The check still │ │ │ occurs by default under Python 2, however the mechanism to test the │ │ │ behavior will be removed in SQLAlchemy 2.0 when Python 2 support is also │ │ │ removed.
│ │ │This logic was very effective when it was needed, however now that Python 3
│ │ │ @@ -9333,21 +9340,14 @@
│ │ │ dialect flags by setting the dialect level flag returns_unicode_strings
│ │ │ to one of String.RETURNS_CONDITIONAL or
│ │ │ String.RETURNS_BYTES, both of which will enable Unicode conversion
│ │ │ even under Python 3.
References: #5315
│ │ │ │ │ │[engine] [performance] ¶
The pool “pre-ping” feature has been refined to not invoke for a DBAPI │ │ │ -connection that was just opened in the same checkout operation. pre ping │ │ │ -only applies to a DBAPI connection that’s been checked into the pool │ │ │ -and is being checked out again.
│ │ │ -References: #4524
│ │ │ - │ │ │ -[engine] [bug] ¶
Revised the Connection.execution_options.schema_translate_map
│ │ │ feature such that the processing of the SQL statement to receive a specific
│ │ │ schema name occurs within the execution phase of the statement, rather than
│ │ │ at the compile phase. This is to support the statement being efficiently
│ │ │ cached. Previously, the current schema being rendered into the statement
│ │ │ for a particular run would be considered as part of the cache key itself,
│ │ │ meaning that for a run against hundreds of schemas, there would be hundreds
│ │ │ ├── html2text {}
│ │ │ │ @@ -6406,15 +6406,21 @@
│ │ │ │ returned by the ResultProxy is now the LegacyRow subclass, which maintains
│ │ │ │ mapping/tuple hybrid behavior, however the base _R_o_w class now behaves more
│ │ │ │ fully like a named tuple.
│ │ │ │ See also
│ │ │ │ _R_o_w_P_r_o_x_y_ _i_s_ _n_o_ _l_o_n_g_e_r_ _a_ _“_p_r_o_x_y_”_;_ _i_s_ _n_o_w_ _c_a_l_l_e_d_ _R_o_w_ _a_n_d_ _b_e_h_a_v_e_s_ _l_i_k_e_ _a_n_ _e_n_h_a_n_c_e_d
│ │ │ │ _n_a_m_e_d_ _t_u_p_l_e
│ │ │ │ References: _#_4_7_1_0
│ │ │ │ -[[eennggiinnee]] [[cchhaannggee]] [[ppeerrffoorrmmaannccee]] [[ppyy33kk]] _¶
│ │ │ │ +[[eennggiinnee]] [[ppeerrffoorrmmaannccee]] _¶
│ │ │ │ +The pool “pre-ping” feature has been refined to not invoke for a DBAPI
│ │ │ │ +connection that was just opened in the same checkout operation. pre ping only
│ │ │ │ +applies to a DBAPI connection that’s been checked into the pool and is being
│ │ │ │ +checked out again.
│ │ │ │ +References: _#_4_5_2_4
│ │ │ │ +[[eennggiinnee]] [[ppeerrffoorrmmaannccee]] [[cchhaannggee]] [[ppyy33kk]] _¶
│ │ │ │ Disabled the “unicode returns” check that runs on dialect startup when running
│ │ │ │ under Python 3, which for many years has occurred in order to test the current
│ │ │ │ DBAPI’s behavior for whether or not it returns Python Unicode or Py2K strings
│ │ │ │ for the VARCHAR and NVARCHAR datatypes. The check still occurs by default under
│ │ │ │ Python 2, however the mechanism to test the behavior will be removed in
│ │ │ │ SQLAlchemy 2.0 when Python 2 support is also removed.
│ │ │ │ This logic was very effective when it was needed, however now that Python 3 is
│ │ │ │ @@ -6422,20 +6428,14 @@
│ │ │ │ datatypes. In the unlikely case that a third party DBAPI does not support this,
│ │ │ │ the conversion logic within _S_t_r_i_n_g is still available and the third party
│ │ │ │ dialect may specify this in its upfront dialect flags by setting the dialect
│ │ │ │ level flag returns_unicode_strings to one of String.RETURNS_CONDITIONAL or
│ │ │ │ String.RETURNS_BYTES, both of which will enable Unicode conversion even under
│ │ │ │ Python 3.
│ │ │ │ References: _#_5_3_1_5
│ │ │ │ -[[eennggiinnee]] [[ppeerrffoorrmmaannccee]] _¶
│ │ │ │ -The pool “pre-ping” feature has been refined to not invoke for a DBAPI
│ │ │ │ -connection that was just opened in the same checkout operation. pre ping only
│ │ │ │ -applies to a DBAPI connection that’s been checked into the pool and is being
│ │ │ │ -checked out again.
│ │ │ │ -References: _#_4_5_2_4
│ │ │ │ [[eennggiinnee]] [[bbuugg]] _¶
│ │ │ │ Revised the _C_o_n_n_e_c_t_i_o_n_._e_x_e_c_u_t_i_o_n___o_p_t_i_o_n_s_._s_c_h_e_m_a___t_r_a_n_s_l_a_t_e___m_a_p feature such that
│ │ │ │ the processing of the SQL statement to receive a specific schema name occurs
│ │ │ │ within the execution phase of the statement, rather than at the compile phase.
│ │ │ │ This is to support the statement being efficiently cached. Previously, the
│ │ │ │ current schema being rendered into the statement for a particular run would be
│ │ │ │ considered as part of the cache key itself, meaning that for a run against
│ │ ├── ./usr/share/doc/python-sqlalchemy-doc/html/changelog/changelog_20.html
│ │ │ @@ -9660,45 +9660,45 @@
│ │ │
[sqlite] [usecase] ¶
Added RETURNING support for the SQLite dialect. SQLite supports RETURNING │ │ │ since version 3.35.
│ │ │References: #6195
│ │ │ │ │ │[sqlite] [usecase] ¶
The SQLite dialect now supports UPDATE..FROM syntax, for UPDATE statements │ │ │ +
[sqlite] [usecase] [performance] ¶
SQLite datetime, date, and time datatypes now use Python standard lib
│ │ │ +fromisoformat() methods in order to parse incoming datetime, date, and
│ │ │ +time string values. This improves performance vs. the previous regular
│ │ │ +expression-based approach, and also automatically accommodates for datetime
│ │ │ +and time formats that contain either a six-digit “microseconds” format or a
│ │ │ +three-digit “milliseconds” format.
References: #7029
│ │ │ + │ │ │ +[sqlite] [usecase] ¶
The SQLite dialect now supports UPDATE..FROM syntax, for UPDATE statements
│ │ │ that may refer to additional tables within the WHERE criteria of the
│ │ │ statement without the need to use subqueries. This syntax is invoked
│ │ │ automatically when using the Update construct when more than
│ │ │ one table or other entity or selectable is used.
References: #7185
│ │ │ │ │ │[sqlite] [performance] [bug] ¶
The SQLite dialect now defaults to QueuePool when a file
│ │ │ +
[sqlite] [performance] [bug] ¶
The SQLite dialect now defaults to QueuePool when a file
│ │ │ based database is used. This is set along with setting the
│ │ │ check_same_thread parameter to False. It has been observed that the
│ │ │ previous approach of defaulting to NullPool, which does not
│ │ │ hold onto database connections after they are released, did in fact have a
│ │ │ measurable negative performance impact. As always, the pool class is
│ │ │ customizable via the create_engine.poolclass parameter.
See also
│ │ │ │ │ │References: #7490
│ │ │ │ │ │[sqlite] [performance] [usecase] ¶
SQLite datetime, date, and time datatypes now use Python standard lib
│ │ │ -fromisoformat() methods in order to parse incoming datetime, date, and
│ │ │ -time string values. This improves performance vs. the previous regular
│ │ │ -expression-based approach, and also automatically accommodates for datetime
│ │ │ -and time formats that contain either a six-digit “microseconds” format or a
│ │ │ -three-digit “milliseconds” format.
References: #7029
│ │ │ - │ │ │ -[sqlite] [bug] ¶
Removed the warning that emits from the Numeric type about
│ │ │ DBAPIs not supporting Decimal values natively. This warning was oriented
│ │ │ towards SQLite, which does not have any real way without additional
│ │ │ extensions or workarounds of handling precision numeric values more than 15
│ │ │ significant digits as it only uses floating point math to represent
│ │ │ numbers. As this is a known and documented limitation in SQLite itself, and
│ │ │ not a quirk of the pysqlite driver, there’s no need for SQLAlchemy to warn
│ │ │ ├── html2text {}
│ │ │ │ @@ -6632,14 +6632,22 @@
│ │ │ │ See also
│ │ │ │ _R_e_f_l_e_c_t_i_n_g_ _i_n_t_e_r_n_a_l_ _s_c_h_e_m_a_ _t_a_b_l_e_s
│ │ │ │ References: _#_8_2_3_4
│ │ │ │ [[ssqqlliittee]] [[uusseeccaassee]] _¶
│ │ │ │ Added RETURNING support for the SQLite dialect. SQLite supports RETURNING since
│ │ │ │ version 3.35.
│ │ │ │ References: _#_6_1_9_5
│ │ │ │ +[[ssqqlliittee]] [[uusseeccaassee]] [[ppeerrffoorrmmaannccee]] _¶
│ │ │ │ +SQLite datetime, date, and time datatypes now use Python standard lib
│ │ │ │ +fromisoformat() methods in order to parse incoming datetime, date, and time
│ │ │ │ +string values. This improves performance vs. the previous regular expression-
│ │ │ │ +based approach, and also automatically accommodates for datetime and time
│ │ │ │ +formats that contain either a six-digit “microseconds” format or a three-digit
│ │ │ │ +“milliseconds” format.
│ │ │ │ +References: _#_7_0_2_9
│ │ │ │ [[ssqqlliittee]] [[uusseeccaassee]] _¶
│ │ │ │ The SQLite dialect now supports UPDATE..FROM syntax, for UPDATE statements that
│ │ │ │ may refer to additional tables within the WHERE criteria of the statement
│ │ │ │ without the need to use subqueries. This syntax is invoked automatically when
│ │ │ │ using the _U_p_d_a_t_e construct when more than one table or other entity or
│ │ │ │ selectable is used.
│ │ │ │ References: _#_7_1_8_5
│ │ │ │ @@ -6649,22 +6657,14 @@
│ │ │ │ It has been observed that the previous approach of defaulting to _N_u_l_l_P_o_o_l,
│ │ │ │ which does not hold onto database connections after they are released, did in
│ │ │ │ fact have a measurable negative performance impact. As always, the pool class
│ │ │ │ is customizable via the _c_r_e_a_t_e___e_n_g_i_n_e_._p_o_o_l_c_l_a_s_s parameter.
│ │ │ │ See also
│ │ │ │ _T_h_e_ _S_Q_L_i_t_e_ _d_i_a_l_e_c_t_ _u_s_e_s_ _Q_u_e_u_e_P_o_o_l_ _f_o_r_ _f_i_l_e_-_b_a_s_e_d_ _d_a_t_a_b_a_s_e_s
│ │ │ │ References: _#_7_4_9_0
│ │ │ │ -[[ssqqlliittee]] [[ppeerrffoorrmmaannccee]] [[uusseeccaassee]] _¶
│ │ │ │ -SQLite datetime, date, and time datatypes now use Python standard lib
│ │ │ │ -fromisoformat() methods in order to parse incoming datetime, date, and time
│ │ │ │ -string values. This improves performance vs. the previous regular expression-
│ │ │ │ -based approach, and also automatically accommodates for datetime and time
│ │ │ │ -formats that contain either a six-digit “microseconds” format or a three-digit
│ │ │ │ -“milliseconds” format.
│ │ │ │ -References: _#_7_0_2_9
│ │ │ │ [[ssqqlliittee]] [[bbuugg]] _¶
│ │ │ │ Removed the warning that emits from the _N_u_m_e_r_i_c type about DBAPIs not
│ │ │ │ supporting Decimal values natively. This warning was oriented towards SQLite,
│ │ │ │ which does not have any real way without additional extensions or workarounds
│ │ │ │ of handling precision numeric values more than 15 significant digits as it only
│ │ │ │ uses floating point math to represent numbers. As this is a known and
│ │ │ │ documented limitation in SQLite itself, and not a quirk of the pysqlite driver,