Location of "string lookup" for classes in a declarative base?

[Brendan Blanchard]

Hi all,

I'm using a class factory to dynamically generate SQLA types and am rightfully getting the warning:

SAWarning: This declarative base already contains a class with the same class name and module name as <module.class_name>, and will be replaced in the string-lookup table.

when I attempt to use it twice for the same parameters. But, what I was hoping to do was use said string-lookup table (which I can't seem to find in base.metadata or elsewhere) in my class factory such that I can call it as many times as I want (instead of using it once and keeping a reference), and it would return a reference to that already-created class instead of generating the identical new one and the subsequent warning.

Essentially I'd like something like:

def create_cls(cls_name, tablename):

    if cls_name in Base.metadata.string_lookup_table:

        return Base.metadata.string_lookup_table[cls_name]

    <....>

    return type(cls_name, (Base,), some_dynamic_attrs_n_stuff)

The given answer here generates an error for Base not having an _decl_class_registry attribute (I'm using 1.4.3 if that helps), though any solution that uses the tablename or class/module name will work for my case.

Thanks,

Brendan

[Mike Bayer]

we haven't made a public APi for this however the discussion of what it would look like is at https://github.com/sqlalchemy/sqlalchemy/issues/6080  and the proposal is at https://github.com/sqlalchemy/sqlalchemy/issues/6080#issuecomment-801253683.

What you can do now is use sqlalchemy.orm.registry explicitly for your mappings, your class name lookup is in there right now in registry._class_registry

--

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 view this discussion on the web visit https://groups.google.com/d/msgid/sqlalchemy/c2ab6ab1-e6bd-4521-b064-28492300a6cdn%40googlegroups.com.

[Brendan Blanchard]

Thanks Mike,

Glad to see it's in the works.

As for my case, I sometimes forget I'm working in sqlalchemy and Python, and completely overlook simple Python solutions to seemingly-sqlalchemy related issues. Since I have a class factory (which is the only place these classes will come from), I can keep my own lookup table as part of the factory, rather than worrying about where sqlalchemy keeps it. At least for my limited case there's no reason the information *has* to come from the internal sqlalchemy registry.

Thanks again,

Brendan

You received this message because you are subscribed to a topic in the Google Groups "sqlalchemy" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sqlalchemy/tXDTBHITFb0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sqlalchemy+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sqlalchemy/b97a397c-7711-4215-80be-b419dbf74145%40www.fastmail.com.

[Mike Bayer]

that's great and i wish more folks would see it that way :)

To view this discussion on the web visit https://groups.google.com/d/msgid/sqlalchemy/CAFA3B40EJwYF3yEC1hHTqDRzg_P26Jh%2BbY45VNAAqkyjgY-4Aw%40mail.gmail.com.