Well, there are basically two uses for this. Actually one of this should probably be standard part of sqlalchemy:
a) standardize data types. Currently it seems the datatypes returned seem to be the datatypes returned by the underlying database adapter. That destroys much of the db-independence sqlalchemy provides. b) extend data types, e.g. map certain string columns to a Python class. Quite useful with a number of frameworks that use e.g. zope interfaces, etc. Andreas Am Dienstag, den 24.01.2006, 11:39 -0500 schrieb Michael Bayer: > so youre looking to use the data-conversion properties of a type ? > > Well to do this right now, you can create another Table object where you > explicitly name out all the columns with whatever datatypes you want, and > then create a mapper to that. Although thats a little hackish, since both > tables will have the same name one is going to replace the other. > > It might be a better idea to expand the ColumnProperty object, which is > the "column inside of a mapper" object, to support a type object that > overrides that of the Column object its representing. Or maybe, just the > ability to pass it a function for "preprocessing" and "postprocessing". > Which would you prefer ? > > I'll look into this (the ColumnProperty class is right near the top of > mapping/properties.py). > > Andreas Kostyrka wrote: > > Hi! > > > > Is there any way to make a mapper create columns with a given type > > instead of using the database supplied one? (And I know I could always > > add a property get/set for the column but that makes for ugly > > application level code :(, IMHO). > > > > Andreas > >
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
