associate python types with SQL types

Issue #77 resolved
Mike Bayer repo owner created an issue

email thread:

2006/2/24, Michael Bayer : so, you want a mapping of types.TypeEngine types to python type objects ? I suppose we could add a "python_type" accessor on each TypeEngine (i.e. types.String.python_type == str). would that work ?

Yes that would be perfect. I think the mapping will have to be hard coded since there is no way to get it from the dbapi... Do you think it could also be useful using type checking in the setattr of a mapped class? for instance:

mapped.attribute = 'foo'

if attribute refers to a types.Integer it would fail with a TypeError.

On Feb 24, 2006, at 8:15 AM, Michele Comitini wrote:

Hello Michael,

Thanks for your great piece of software.

I have a question about getting type information from a mapper created with reflection. How do I know the python type of a mapped attribute without having to extract at least one record?

Right now I do this:

colnames = mapper.c.keys()
coltypes = [type(getattr(mapper.select()[0](type(getattr(mapper.select()[0),x)) for x in colnames]

which would fail if I have an empty table This way I know which python types I can expect as a result of a select() on that mapper and what types I have to use on insert. While if do:

If I do this:

colnames = mapper.c.keys()
coltypes = [for x in colnames]((getattr(mapper,x)).type)

I get the sqlalchemy.types (or derivatives) which tell me only the type stored in the db.

This could be useful to check for correct type binding before actually having the driver raising an exception and manage type conversion on the python side.

Thanks for you help and keep up the great work!

Michele Comitini

Comments (4)

  1. Mike Bayer reporter

    theoretically, the type associated with a SQL type might be ambiguous. such as "unicode" or "str" in some cases...sqlite always returns unicode strings for String; everything else returns "str". But even if i have a String that returns 'str', but then if the engine has "convert_unicode=True", it returns 'unicode'. PickleType is ambiguous too.

    i see the need for this kind of thing but i still feel kind of antsy about it being in the core...arent we working in a dynamically-typed language ?

    maybe if i could see a full example of why this is really needed i could get my head around how it sohuld be done.

  2. Former user Account Deleted

    (original author: ram) It's needed to insulate SA users from the variability of various DB-API author choices about what the "best" Python type is for a given SQL type. Is a NUMERIC a float() or a Decimal()? Is a NVARCHAR a str() or unicode()? Right now, you'll get different answers from different DB-API modules.

    SA inhabits a nether-world between statically typed SQL and dynamically typed Python. What's needed is a map to this world, as per our mailing list discussion of TypePolicy. I don't see why the TypePolicy object couldn't be consulted to do run-time introspection of the expected return type of an SQL column without actually running a query to test it.

  3. Log in to comment