[sqlalchemy] refresh_flush instance event not called for PK attributes

Dear Mike and SQLAlchemy users, I think I've discovered a confusing (and undocumented) limitation of the refresh_flush event. It's called when non-PK columns are populated after an INSERT or UPDATE (e.g. from a server-side default), but not for PK values. The

Re: [sqlalchemy] Re: TypeDecorators don't know which database session to use

Hi Mike, On Wed, 29 May 2019 at 15:30, Mike Bayer wrote: > Note that we suggested approaches that work in conjunction with the > serialized approach you gave, the @property approach and the mapper.load() > event approach. > Unfortunately I think they would both require massive code

Re: [sqlalchemy] Re: TypeDecorators don't know which database session to use

Hi all, Thanks for the replies! Sorry, perhaps I wasn't clear, this is just a minimal example. We are actually storing serialized objects in a column, which can be e.g. dicts or lists of (dehydrated) SQLAlchemy objects, numpy arrays, etc. It's much faster to store (both read and write) a

[sqlalchemy] TypeDecorators don't know which database session to use

Dear Michael, I have discovered a limitation of TypeDecorators (custom column types): any one that uses the database (e.g. to load objects serialised in a custom way) has no way to know which database session to use. During initial load one can use a global session object, but expired

[sqlalchemy] Attribute mapped collections

Dear Michael and SQLAlchemy users, I have what may be a minor bug report, and a feature request. The possible bug is that creating an instance of a mapped association object adds it to an attribute-mapped

Re: [sqlalchemy] Making Metadata bases more independent

source files. Are you looking for someone else to implement the tests? It should be easy because we already have a reproducible test case. Thanks, Chris. On Wednesday, 5 December 2018 20:24:09 UTC, Mike Bayer wrote: > > On Wed, Dec 5, 2018 at 11:04 AM Chris Wilson > > wrote: >

[sqlalchemy] Making Metadata bases more independent

Dear Mr Bayer and SQLAlchemy users, We have an issue which probably counts as a feature request rather than a bug, because it's sufficiently esoteric. We need to be able to use some Mappers (in one Metadata) while other mappers (in a different Metadata) are not and cannot be completely

[sqlalchemy] Objects wrongly persistent after rollback

Dear Michael, I have discovered that under very particular circumstances, SQLAlchemy forgets that an object was newly created in a transaction, and if that transaction rolls back, the object's state is not reset from persistent to transient. It seems to rely on the following: *Open

[sqlalchemy] Re: Row versioning not working with multi-table polymorphism

Dear Mike, Thank you very much for the fast reply and workaround! I think it might have been us that originally requested the server-side versioning. We would like to continue using it because we have some large tables that don't really need an additional ID column since the database already

[sqlalchemy] Row versioning not working with multi-table polymorphism

mapper.version_id_col in mapper._cols_by_table[table]: and then tries to execute a null UPDATE just in order to get the new version number, which fails. It would work if we did a dummy update, for example assigning the PK to itself, as this would change the version number (xmin) returned by the s

[sqlalchemy] Relationships not being set to None when related object is deleted

Hi all, I'm having problems with relationships getting out of sync with the underlying foreign key properties, and hoping that someone can help. It seems from the manual (if I've understood correctly), that deleting one side of a relationship should set foreign keys on the other side to

Re: [sqlalchemy] Relationships not being set to None when related object is deleted

Hi Michael, Thanks for replying so quickly! On Wednesday, 28 October 2015 15:04:56 UTC, Michael Bayer wrote: > OK, sorry, you've misunderstood the documentation. When it says > "delete", it refers to the *parent* object that refers to the *child*, > that is, the parent is the one that

[sqlalchemy] Nested transaction rollback does not undo changes to instances

Dear SQLAlchemy developers, I think I've found a problem with SQLAlchemy not rolling back changes to instances that are committed in an inner nested transaction, when the outer nested transaction rolls back. The manual says: When begin_nested()