Andreas Kostyrka wrote:
> 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.
well if you are doing t = Table('mytable', autoload=True), then yes, it
has no choice but to load the datatypes that are in the database, since
you arent telling it anything otherwise. But if you name out the
Table/Columns directly (which i think is a better approach for a real
app), then you can make them whatever types you want.
>
> 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.
the datatypes do this already, and you can make your own too:
http://www.sqlalchemy.org/docs/types.myt#types_custom
The point is though, all this typing happens at the table metadata layer.
It sounds like all you need is some ability to use "autoload=True" with a
Table object, which everyone seems to want to do, but then be able to name
just particular columns where you want to override the datatype, i.e.:
t = Table('mytable', autoload=True,
Column('column3', MyType)
)
Which will reflect 'mytable' and all its columns, replacing just the type
for 'column3' with MyType instead of whatever it pulls in. I like this
because it keeps it all outside of the ORM layer.
- mike
>
> 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
>> >
>
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Sqlalchemy-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
