Paul Johnston wrote:
3) unicode fields
Ticket #298 had been created for this, but is not a complete solution. I
have re-opened the ticker, with this comment:
Unicode columns are still created as VARCHAR. The problem is that
Unicode is a TypeDecorator
like i said in the ticket, all TypeDecorator types define what type
they are wrapping using the impl class member. dialect-specific
Unicode types which want to subclass Unicode need only define a
different impl member so that they wrap whatever String subclass you
want.
Jonathan Ellis wrote:
o2 = orders.select().alias('o2')
max_orders = orders.select(orders.c.order_id==max_order_id).alias('max_orders')
youre not really showing me what you did there fully so its hard for me
to tell how you got that result.
- I take it SA doesn't really support subselects
Jonathan Ellis wrote:
Hmm, another undocumented option... :) How is a viewonly relation on
the class different from a relation on a non_primary mapper?
oh theyre both documented. a non_primary mapper means, you load
instances from the DB using an alternate table/selectable. once those
another thing we might do if you want Unicode to act database-neutral
is add a step at line 85 of types.py to ask the dialect first for a
type_descriptor of Unicode, then if not found to ask for the impl
version which is normally String. The MSSQL dialect would return
NVARCHAR for the Unicode
