On Aug 26, 6:01 pm, Michael Bayer <mike...@zzzcomputing.com> wrote: > On Aug 26, 2009, at 8:53 PM, chris e wrote: > > > > > I just checked the trunk, it the same reflection code is in place, as > > far as the column length is concerned. > > > To me the question is, should sqlalchemy be aware of Char vs Byte > > storage? > > > Is VARCHAR2(400) the same as VARCHAR2(100 CHAR), by storage size it > > is, but do we want storage size or number of characters? > > > I'm not 100% sure. Anyone else out there using oracle, and have an > > opinion. > > oh , I hadn't realized the VARCHAR2(100 CHAR) syntax. in that case we > should stick with data length. the point is that a round trip > reflection back to CREATE TABLE creates the same data type. > > although a thornier issue is, should the number we send to String() > attempt to resolve itself in terms of character length instead of data > length. For that I'd love for Jason to chime in but we might have to > put out the bat signal on the roof for that to happen.
IIRC SQL specifies the length of VARCHARs as characters rather than bytes, and I'd imagine that's what we're currently getting via reflection & DDL generation on most backends. I guess I'd vote for the oracle dialect to do the CHAR annotation for generation for parity with String(...) on other backends. The specter of doing char set detection & width math for reflection is pretty icky though. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
