custom __init__ methods not being invoked

[RM]

I have a class which inherits from Base. My class has a metaclass which inherits from DeclarativeMeta. Among other things, the metaclass adds an __init__ method to the class dictionary. When I instantiate an instance of my class directly, my __init__ method is invoked, but if I use the ORM to retrieve an instance, my __init__ method is not invoked. 

A metaclass serves better than a mixin for what I am trying to accomplish. However, I did experiment with a mixin and saw the same behavior as described above.

Any ideas? Many thanks.

[Michael van Tellingen]

See http://docs.sqlalchemy.org/en/latest/orm/mapper_config.html#constructors-and-object-initialization

> --
> You received this message because you are subscribed to the Google Groups
> "sqlalchemy" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/sqlalchemy/-/oDj_bHNvP7EJ.
> To post to this group, send email to sqlal...@googlegroups.com.
> To unsubscribe from this group, send email to
> sqlalchemy+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sqlalchemy?hl=en.

[Ryan McKillen]

Worked like a charm. Thanks.

— RM

[Ryan McKillen]

It doesn't appear that the method decorated by @orm.reconstructor is called on objects retrieved/loaded as relationships.

Not my desired behavior, but I guess it is consistent with the docs:

"When instances are loaded during a Query operation as in query(MyMappedClass).one(), init_on_load is called."

So if I need it to be executed in a relationship-loading situation, what's the best way to go about it? Thanks.

— RM

[Michael Bayer]

its called in all SQL loading scenarios including that of relationships.

A relationship load might not actually result in the object being loaded from the DB in these scenarios:

1. the relationship is a simple many-to-one, and the object could be located by primary key from the identity map without emitting a SQL load.

2. the relationship emitted the SQL, but as it loaded the rows, the objects matching those rows were already in the identity map, so they weren't reconstructed.

In both scenarios above, the objects were still guaranteed to be present in the identity map in only three possible ways: 

1. they were loaded at some point earlier, in which case your reconstructor was called

2. they moved from "pending" to "persistent" , meaning you added them with add(), then they got inserted, so you'd want to make sure

whatever regular __init__ does is appropriate here

3. the objects were detached, and were add()ed back into the session, but this still implies that #1 or #2 were true for a previous Session.

To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+...@googlegroups.com.

To post to this group, send email to sqlal...@googlegroups.com.

Visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Ryan McKillen]

Thanks for the details. Makes sense.

Still not consistent with what I'm experiencing. Although consistent with what I'm seeing when I put a simple example/test together. I'll keep digging...

— RM