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 <[email protected]> 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 [email protected].
> > To unsubscribe from this group, send email to
> > [email protected].
> > 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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
