[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 {}
│ │ │ │ @@ -6759,14 +6759,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
│ │ │ │ @@ -6776,22 +6784,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,