On Thu, Aug 2, 2018 at 3:00 PM, Wis Kojohnjaratkul <[email protected]> wrote: > 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), 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 is all correct > > 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()) that is correct > > 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. it does not however the issue that calls for one to be built is at: https://bitbucket.org/zzzeek/sqlalchemy/issues/4262/clean-up-typeengine-_default_dialect > 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. pull requests suggesting implementations for the above ticket would be of great help. > > 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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/sqlalchemy. > For more options, visit https://groups.google.com/d/optout. -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
