SQLAlchemy 2.0 is firing an attribute set event on session.commit()

[jace]

I have a validator for some attributes that is configured using @event.listens_for(cls.fkey_id, 'set', raw=True).

In SQLAlchemy 2.0, if session.commit() causes an IntegrityError, it will expire all attributes correction: unset foreign key columns populated via a relationship, and in the process will call this set handler with value=None. This did not happen with 1.4.

There does not appear to be any way to determine that the event handler was called during instance expiry as initiator.op == REPLACE and target.session.is_active is True and target.detached is False and target.expired_attributes == set().

Is this a regression in SQLAlchemy 2.0, or an intended change? How do I identify that the attribute is being expired?

(I can't use the class-level @validates decorator as this event handler is defined outside the class.)

[zzzeek]

hi -

There's no known regression in this area, and there is no such change intended.

How do I identify that the attribute is being expired?

the most expedient way is to look inside of object.__dict__ and see if the key is missing.

there's no detail or example mappings / operations provided here so I know much less about what you are seeing than you do.

[jace]

After some debugging I've found this is happening in a narrower scenario, when a foreign key column is populated using the relationship. Using the standard User and Address examples from the documentation, calling session.add(Address(user=user_with_id_1)), then session.commit() (resulting in an IntegrityError) is causing three calls to the set event handler for the user_id column:

1. oldvalue=LoaderCallableStatus.NO_VALUE, value=1, initiator.op=symbol('REPLACE')
2. oldvalue=1, value=1, initiator.op=symbol('REPLACE')
3. oldvalue=1, value=None, initiator.op=symbol('REPLACE')

Immediately after the failed commit(), address.user continues to have the provided value, but address.user_id has been reset to None. The set event is not called on object expiry – I was mistaken. It appears to be called when a relationship's foreign key is populated into the attribute, and then unset again (which did not seem to happen in 1.4).

I'm debugging a largish project tonight and haven't got around to extracting sample code — my apologies.

[jace]

object.__dict__ does not have user_id at the time of the first set event, but has it during the second and third events (which seems correct as this is not attribute expiry).

Is there any way I can identify that the set call is populating a foreign key column attached to a relationship? If not, I'll have to refactor to point the event handler at the relationship attribute instead of the foreign key.

[zzzeek]

usually I put a pdb in my attribute event, or failing that, directly into SQLAlchemy attributes.py -> __set__(), and that will show attribute level set events plus the ability to say "where" and show the stack trace.

you can also try a git bisect on SQLAlchemy to see where the behavior changes, that would certainly provide a clue. it might have nothing to do with attributes.

[jace]

I've resolved this for now by changing my test (where this came up) to set the fkey column instead of the relationship. I'll come back to this when the rest of the migration is done.

[CaselIT]

if you can create a reproducing case it would be nice to have a look at it to understand if there is a regression or the different behaviour is expected