[sqlalchemy] Re: Uninitialized coltype in PGDialect.get_columns() for custom column basetype
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', unextval('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.
Re: [sqlalchemy] Re: Uninitialized coltype in PGDialect.get_columns() for custom column basetype
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', unextval('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
