Hi, I'm currently working on an external dialect for SQLAlchemy to work with the Teradata database and am running into issues with printing out/calling str() on non-SQL standard types implemented by the dialect. For example, the NUMBER type I've implemented cannot be printed out with a simple call to print().
If we run the following statement: print(sqlalchemy_teradata.NUMBER(precision=38, scale=10)) or equivalently: str(sqlalchemy_teradata.NUMBER(precision=38, scale=10)) We should get the following error: UnsupportedCompilationError: Compiler <sqlalchemy.sql.compiler.GenericTypeCompiler object at 0x111d611d0> can't render element of type <class 'sqlalchemy_teradata.types.NUMBER'> To my understanding, this is happening because __str__() is attempting to compile the TypeEngine instance with the GenericTypeCompiler, which doesn't define a visit_NUMBER method. Looking further into this (especially around here <https://github.com/zzzeek/sqlalchemy/blob/master/lib/sqlalchemy/sql/type_api.py#L579>), I've come to the conclusion that the GenericTypeCompiler is being called to compile the type because __str__() calls compile() on the type without a dialect argument, which in turn acquires the default dialect with a call to _default_dialect(). Now, I suspect because the Teradata dialect is an external dialect, the sub-dialect check that looks at the type's __module__ will return false and default.DefaultDialect will be returned. Because of this, the GenericTypeCompiler is called to handle compiling the dialect-specific type which unsurprisingly causes the error. That being said, to achieve the same effect we can certainly circumvent the aforementioned error by doing the following instead: sqlalchemy_teradata.NUMBER(precision=38, scale=10).compile(dialect= TeradataDialect()) But this seems rather unnecessarily cumbersome for users. Therefore, I'm curious to know whether SQLAlchemy provides a straightforward facility by which external dialects can specify a default dialect for their type implementations so that print() and str() calls can work properly on their dialect-defined types. I'm currently resorting to explicitly overriding __str__ in all our dialect-specific types which I suspect may not be the best, nor the intended, way to go about it. Any advice regarding this topic is greatly appreciated. Thanks, Wis -- 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+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at https://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
