OK, i propose we make the KeyError more friendly, and add an option
skip_unknown_types to Table to indicate just to skip the columns. if
we really want the default fallback type, id prefer an option for
that too, like default_type=sometype and it will shove that type in
for the unknown types.
Additionally we have to implement this for all the dialects, not just
PG. if you guys want to work up a ticket/patch for this that would
be great (im falling behind on tickets).
On Feb 16, 2007, at 2:55 PM, Jonathan Ellis wrote:
I'd prefer to not have them loaded at all (maybe with log.warning)
than to have them loaded with a known-to-be-incorrect type.
If you really don't want to manipulate them from Python, not loading
them is the Right Thing. If you do want to manipulate them then the
Right Thing is to add the necessary datatypes.
On 2/16/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I found the discussion last month regarding the lack of support for
specialised datatypes in the postgres reflection code.
I have a lot of odd datatypes in my schemas... besides inet, there's
postgis datatypes and tsearch2's tsvector, etc. However, most of
these
odd fields are never manipulated directly at the python level (they
tend to be updated internally via triggers); and the ones that are
touched (like 'inet' for example) work fine as text fields.
Postgresql
does the coersion.
Thus, my quick little hack to make reflection work without having to
tediously override the table columns, or create new datatypes, is
simply to make all unknown datatypes be 'text' datatypes:
--- postgres.py.origFri Feb 16 09:52:59 2007
+++ postgres.py Fri Feb 16 09:55:26 2007
@@ -392,7 +392,10 @@
elif attype == 'timestamp without time zone':
kwargs['timezone'] = False
-coltype = ischema_names[attype]
+if ischema_names.has_key(attype):
+coltype = ischema_names[attype]
+else:
+coltype = ischema_names['text']
coltype = coltype(*args, **kwargs)
colargs= []
if default is not None:
I realise this is a bit dodgy, but it has simplified things for me
greatly. I'm wondering if something like this might not be a useful
concept for an some sort of autoload option... rather than crashing
with a KeyError. Either a default datatype to substitute, or even
just
ignoring fields of unknown datatypes.
(Also it would be very helpful, especially when autoloading a lot of
foreign key tables, if that KeyError exception was caught and
returned
a more meaningful error message... like what table and field name is
the problem...)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
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
-~--~~~~--~~--~--~---
