The change to "evaluates none" datatypes in the ORM was not fully described in the migration notes, missing the key behavioral change that a column which is missing a default entirely will not receive a value for a missing JSON column now. The issue here touched upon a revisit of the assumptions in [ticket:3514], but overall the old behavior "worked" mostly because the ORM wants to explicitly render NULL into an INSERT for column values that are missing, which itself is a legacy behavior which should be considered for possible removal in a future major release. Given that "missing ORM value + no column default set up == dont put it in the INSERT" would be the most intuitive behavior, the move in [ticket:3514] represents a step in this direction. Change-Id: I454d5bb0773bd73d9864925dcc47f1f0810e33ba Fixes: #3830
ORM attributes can now be assigned any object that is has a ``__clause_element__()`` attribute, which will result in inline SQL the way any :class:`.ClauseElement` class does. This covers other mapped attributes not otherwise transformed by further expression constructs. As part of this, it was considered that we could add __clause_element__() to ClauseElement, however this causes endless loops in a "while" pattern and this pattern has been identified in third party libraries. Add a test to ensure we never make that change. Change-Id: I9e15b3f1c4883fd3909acbf7dc81d034c6e3ce1d Fixes: #3802
Removes an unnecessary transfer of modified PK column value to the params dictionary, so that if the modified PK column is already present in value_params, this remains in effect. Also propagate a new flag through to _emit_update_statements() that will trip "return_defaults()" across the board if a PK col w/ SQL expression change is present, and pull this PK value in _postfetch as well assuming we're an UPDATE. Change-Id: I9ae87f964df9ba8faea8e25e96b8327f968e5d1b Fixes: #3801
Currently, ``Session.bulk_insert_mappings`` omits NULL values which causes it to break up batches of inserts based on which batches contain NULL and which do not. By adding this flag, the same columns are rendered in the INSERT for all rows allowing them to be batched. The downside is that server-side defaults are omitted. Doctext-author: Mike Bayer <mike_mp@zzzcomputing.com> Change-Id: Iec5969304d4bdbf57290b200331bde02254aa3a5 Pull-request: https://github.com/zzzeek/sqlalchemy/pull/243
would still potentially cause persistence conflicts on the next transaction, because the instance would not be checked that it was expired. This fix will resolve a large class of cases that erronously cause the "New instance with identity X conflicts with persistent instance Y" error. fixes #3677
available mapper options. This allows a DELETE to proceed for a joined-table inheritance mapping against the base table only, while allowing for ON DELETE CASCADE to handle deleting the row from the subclass tables. fixes #2349
the same cached starting statement each time. no issue has been observed with the former but it could perhaps have issues w/ versioning or eager_defaults
would not bump a version id counter when in use. The experience here is still a little rough as the original version id is required in the given dictionaries and there's not clean error reporting on that yet. fixes #3610
insert-default holding columns not otherwise included in the SET clause (such as primary key cols) to get rendered into the RETURNING even though this is an UPDATE. - Major fixes to the :paramref:`.Mapper.eager_defaults` flag, this flag would not be honored correctly in the case that multiple UPDATE statements were to be emitted, either as part of a flush or a bulk update operation. Additionally, RETURNING would be emitted unnecessarily within update statements. fixes #3609