Sorry I was being a bit lazy and trying to avoid setting up the PG test environment. The problem affects a domain over a custom type. Here is a test that exhibits the behaviour (without assertions):
class DomainOverCustomTypeReflectionTest(TestBase, AssertsExecutionResults): __only_on__ = 'postgresql' @classmethod def setup_class(cls): con = testing.db.connect() con.execute("CREATE TYPE testtype AS ENUM ('test')") con.execute('CREATE DOMAIN testdomain AS testtype') con.execute('CREATE TABLE testtable (question integer, answer testdomain)') @classmethod def teardown_class(cls): con = testing.db.connect() con.execute('DROP TABLE testtable') con.execute('DROP DOMAIN testdomain') con.execute('DROP TYPE testtype') def test_domain_is_reflected(self): metadata = MetaData(testing.db) table = Table('testtable', metadata, autoload=True) Thanks, N On Sep 29, 9:58 pm, Michael Bayer <mike...@zzzcomputing.com> wrote: > On Sep 29, 2010, at 3:37 PM, Nikolaj wrote: > > > > > Hi there, > > > I use the earthdistance and cube modules for PostgreSQL (http:// > >www.postgresql.org/docs/8.4/interactive/earthdistance.html). These > > define some custom types and functions for doing great circle > > calculations. I ran into a problem with table introspection in > > PGDialect.get_columns(). > > > The columns and domains fetched look like this (note that the 'earth' > > type defined by the earthdistance module has the base type of 'cube' > > from the cube module): > > > rows = [ > > (u'id', u'integer', u"nextval('mytable_id_seq'::regclass)", True, 1, > > 161772), > > (u'created_at', u'timestamp without time zone', None, True, 2, > > 161772), > > (u'name', u'character varying(255)', None, True, 3, 161772), > > (u'lat', u'numeric(10,7)', None, False, 4, 161772), > > (u'lng', u'numeric(10,7)', None, False, 5, 161772), > > (u'earth', u'earth', None, False, 6, 161772) > > ] > > > domains = { > > u'earth': {'attype': u'cube', 'default': None, 'nullable': True}, > > u'information_schema.cardinal_number': {'attype': u'integer', > > 'default': None, > > 'nullable': True}, > > u'information_schema.character_data': {'attype': u'character > > varying', > > 'default': None, > > 'nullable': True}, > > u'information_schema.sql_identifier': {'attype': u'character > > varying', > > 'default': None, > > 'nullable': True}, > > u'information_schema.time_stamp': {'attype': u'timestamp', > > 'default': > > u"('now'::text)::timestamp(2) with time zone", > > 'nullable': True} > > } > > > The problem is that in the loop through the rows in > > PGDialect.get_columns(), the 'earth' column's attype is in the > > dictionary of domains, but the domain attype (cube) is not in > > self.ischema_names. So coltype is never initialized, and it ends up > > having the value of the previous for loop iteration, causing it to > > fail with "TypeError: 'NUMERIC' object is not callable" (because the > > previous iteration ran coltype = coltype(...)). > > > The expected behaviour is obviously for `coltype` to become > > sqltypes.NULLTYPE. It can be solved by initializing coltype = None > > inside the for loop. > > Hi - can you please illustrate a short test for this. I dont work with PG > domains myself so its not immediately clear to me what this means exactly, is > it the case that this is a domain of a domain ? if so wouldnt we want "cube" > to be in the "domains" list as well ? > > We have quite a few tests for reflecting types from domains in > test/dialects/test_postgresql.py so a test would need to be added there once > a solution is decided upon. > > > > > Thanks, > > > N > > > -- > > You received this message because you are subscribed to the Google Groups > > "sqlalchemy" group. > > To post to this group, send email to sqlalch...@googlegroups.com. > > To unsubscribe from this group, send email to > > sqlalchemy+unsubscr...@googlegroups.com. > > For more options, visit this group > > athttp://groups.google.com/group/sqlalchemy?hl=en. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.