great, that test is perfect. I added ticket #1933, I just want to see if I
can get the "testtype" to be available somehow before falling back to setting
coltype=None solution.
On Sep 30, 2010, at 9:22 AM, Nikolaj wrote:
> 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.
>
--
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.
