If we prefer it to be characters, then we should probably use CHAR_LENGTH instead of DATA_LENGHT when reflecting, and add the CHAR specifier to the column generators. I can put together a patch if that helps.
On Aug 27, 10:02 am, jek <[email protected]> wrote: > On Aug 26, 6:01 pm, Michael Bayer <[email protected]> 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 [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 -~----------~----~----~----~------~----~------~--~---
