On Jun 10, 2010, at 8:51 AM, Cserna, Zsolt wrote: >> >> >> SQLAlchemy doesn't do type coercion out of the box. Some >> DBAPIs do, which is why you may have not noticed this issue >> on other platforms. You can build that functionality >> yourself using TypeDecorator: >> >> http://www.sqlalchemy.org/docs/reference/sqlalchemy/types.htm?highlight=typedecorator#sqlalchemy.types.TypeDecorator > > > I've fixed my problem with the TypeDecorator you suggested. Thanks. > > Just to fix that, sqlalchemy doesn't do type coercion by default, and it will > never do it. Is it correct? > > In my test application I was able to replace the Integer type to the > decorated one, which is fine, but requires the same 4-line code for my > projects. It would be better if sqlalchemy would do it for me by default but > if it doesn't fit to the design I can accept that.
from string-> something is not always a clean cut affair (though it is for int()) , but it also adds overhead to the usage of bind parameters, which can add up if you're doing an executemany() style call with thousands of parameter sets. Its better that this additional behavior is left up to extensions. Any non-trivial SQLAlchemy project would usually have a "util.py" of some sort that contains a set of SQLAlchemy idioms for usage throughout the application. In mine I usually have a whole set of types that are specific to the use case at hand, column-generating macros that enforce naming schemes, stuff like that. -- 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.
