- changed milestone to blue sky
associate python types with SQL types
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)
-
reporter -
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.
-
reporter the Python types returned for various SQLA types are now well defined and mostly consistent in practice, so this is a non-controversial feature which is added in a708d0fbce3b7d8a9fb575bab5229a9b6b5f8f3a.
-
reporter - removed milestone
Removing milestone: 0.7.4 (automated comment)
- Log in to comment
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.