"No such polymorphic_identity" when models in different modules

[natsjoo sodillepa]

Hi all,

I got an "No such polymorphic_identity" error in the following situation:

- I use Declerative and joined table polymorfism style

- moduleA defines Base, and a lot of Classes, one of them ClassA1(Base) and ClassA2(Base)

- moduleB contains a subclassed ClassB(ClassA1)

- ClassA2 contains a 1:n relation with ClassA1

when I try to get the list of ClassA1 objects of ClassA2 I get a "No such polymorphic_identity"

error.

However, if I put everything in the same file things work fine.

So my question is: can I put subclasses in different modules and if so: how?

Kind regards,

Nacho

[Simon King]

SQLAlchemy doesn't care if your classes are defined in a single file
or multiple files.

When you got the error, is it possible that you hadn't imported
moduleB? If you haven't imported it, SQLAlchemy will have no idea that
ClassB exists.

Simon

> --
> SQLAlchemy -
> The Python SQL Toolkit and Object Relational Mapper
>
> http://www.sqlalchemy.org/
>
> To post example code, please provide an MCVE: Minimal, Complete, and Verifiable Example. See http://stackoverflow.com/help/mcve for a full description.
> ---
> You received this message because you are subscribed to the Google Groups "sqlalchemy" group.
> 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 https://groups.google.com/group/sqlalchemy.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sqlalchemy/53a77b0e-b28c-4c1d-a54a-ffac09cfb5be%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[natsjoo sodillepa]

@Simon.

Interesting point. I create the DB and the instances in one script. The data in the db seems to be correct.

However the error occurs in a second script which almost is like this:

import ClassA2

... create session ...

objectA2 = session.query(ClassA2).first()

for objectA1 in objectA2.list_objectA1:

    objectA1.do_something()

So, no here I don't import ClassA1, but I shouldn't, should I (?).

The error occurs on entering the for loop.

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

[Mike Bayer]

On Thu, Jul 4, 2019, at 8:14 AM, natsjoo sodillepa wrote:

@Simon.

Interesting point. I create the DB and the instances in one script. The data in the db seems to be correct.

However the error occurs in a second script which almost is like this:

import ClassA2

... create session ...

objectA2 = session.query(ClassA2).first()

for objectA1 in objectA2.list_objectA1:

    objectA1.do_something()

So, no here I don't import ClassA1, but I shouldn't, should I (?).

The error occurs on entering the for loop.

SQLAlchemy has to know about all the classes before you do a query that's going to refer to a remote class' polymorphic_identity, so somewhere you have to make sure the module was imported.   

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 https://groups.google.com/group/sqlalchemy.

To view this discussion on the web visit https://groups.google.com/d/msgid/sqlalchemy/a4af5e8f-d17a-4fd8-a0d4-5fb6a058b998%40googlegroups.com.

[natsjoo sodillepa]

@MIke

 

SQLAlchemy has to know about all the classes before you do a query that's going to refer to a remote class' polymorphic_identity, so somewhere you have to make sure the module was imported.   

I imported the subclass and indeed now "it works". At first this is counter intuitive, but I understand the need.

The point now is that I don't really want to know what subclasses there are (hence the polymorfism), so now

I've to find a way to import all relevant modules. I'll figure this out but any ideas are welcome.

Anyway: thanks both Mike & Simon for pointing this out.

Nacho

[natsjoo sodillepa]

For the curious. One thing that lingers around is the question: how does SQLalchemy make the connection between the parent and the child classes?

In the separate modules, where the child classes are defined there is no other code. The only thing that gets executed is the class construction, but as

far as I know that doesn't trigger execution of code in the parent class. I know that SQLalchemy uses a metaclass but that's used only for

instantiation of instances, not of classes, or is it?

[Simon King]

In Python, modules are executed when they are imported. Class
definitions are executable statements, where the metaclass is called
to construct the *class*. When you import a module containing
declarative classes, the SQLAlchemy metaclass is called for each of
those classes, building the mappings, registering the polymorphic
identities and so on.

Simon

> --
> SQLAlchemy -
> The Python SQL Toolkit and Object Relational Mapper
>
> http://www.sqlalchemy.org/
>
> To post example code, please provide an MCVE: Minimal, Complete, and Verifiable Example. See http://stackoverflow.com/help/mcve for a full description.
> ---
> You received this message because you are subscribed to the Google Groups "sqlalchemy" group.
> 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 https://groups.google.com/group/sqlalchemy.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sqlalchemy/c90cafee-13a4-4759-99a7-b2fd656697b2%40googlegroups.com.

[Mike Bayer]

To view this discussion on the web visit https://groups.google.com/d/msgid/sqlalchemy/CAFHwexebd5F9HXSX_kcBCY3Xey9aiPLThLX3h6GD1v7bomXd%3Dg%40mail.gmail.com.

[Mike Bayer]

On Fri, Jul 5, 2019, at 6:16 AM, Simon King wrote:

In Python, modules are executed when they are imported. Class

definitions are executable statements, where the metaclass is called

to construct the *class*. When you import a module containing

declarative classes, the SQLAlchemy metaclass is called for each of

those classes, building the mappings, registering the polymorphic

identities and so on.

The pattern from a software architecture point of view was identified by Martin Fowler as the "registry" pattern, https://martinfowler.com/eaaCatalog/registry.html, however this pattern doesn't say much about the mechanics used.    The registry pattern refers to linking the creation of a class or object to its automatic inclusion in some semi-global or in some cases global registry, which is one SQLAlchemy uses a lot, in some cases explicitly and in other cases only behind the scenes.

The declarative metaclass contains a function which scans your class for attributes, builds a Table from these attributes which is associated with the MetaData collection that the metaclass has access towards (this is registry pattern #1).  Then, the mapper() function is invoked against the class you created along with this Table, which creates a new Mapper object that is added to a global, weak-referencing collection inside the sqlalchemy.orm.mapper module (this is registry pattern #2).  When the mapper "inherits" from another one as seems to be the case here, that inheriting mapper is also amended to include this new mapper in its collection of subclasses.

The overall "mapper configure" step which you may have seen scans through this registry of mapper objects and makes sure all the mappers that refer to each other, usually through the relationship() linkage, are fully linked and have been found.

To view this discussion on the web visit https://groups.google.com/d/msgid/sqlalchemy/CAFHwexebd5F9HXSX_kcBCY3Xey9aiPLThLX3h6GD1v7bomXd%3Dg%40mail.gmail.com.

[natsjoo sodillepa]

Got it.

As I like to "eat the pudding":

x.py:

class Meta(type):
   print("Here is Meta")
   def __new__(cls, name, bases, dct):
      print("meta.new")
      return super().__new__(cls, name, bases, dct)

class Foo(metaclass=Meta):
   print("Here is Foo")

y.py:

from x import Foo

class What(Foo):
   print("Here's What, a Foo")

Giving as output on python y.py:

Here is Meta
Here is foo
meta.new
Here's What, a Foo
meta.new

Showing that the meta class indeed is called on construction of "What": hence there you have the mechanics of class registration.

Now that's covered I've to say I'm not too happy importing module's with no apparent use, but that seems the nature of the beast.

Kind regards,

Nacho