From: Luke O. <lu...@me...> - 2003-05-05 15:17:29
|
Hello - Having some issues with application of styles and changed behavior from the previous default 'style'. (This is all from CVS late last week..) 1. Double capitals in table and column names are treated differently from before: ie, 'PProductXType' used to generate 'p_product_x_type', now generates 'pproduct_xtype'. It's not a very pretty name by itself, but the new conversion is fairly unexpected to me regardless. Simple changes to the RE ('[A-Z]' instead of '[A-Z]+') and not treating tablenames different from column names fixes these. In general I guess we may start using our own style object, but I'm just concerned that the new default Style breaks old (simpler) behavior. 2. '_defaultOrder' in 0.3 and in my original suggestion would accept either database-style or python-style names. It now assumes it is in database-style. Simple fix is to put check that used to be in the metaclass back in (modified to use styles): line 135ish: if hasattr(newClass, '_defaultOrder') and newClass._defaultOrder: if newClass._defaultOrder != \ newClass._style.pythonAttrToDBColumn(newClass._defaultOrder): newClass._defaultOrder = \ newClass._style.pythonAttrToDBColumn(newClass._defaultOrder) However, this will only work in the general case if Style functions are discrete: pythonAttrToDBColumn(pythonAttrToDBColumn(name)) returns the same value as one call (in the default style, this is accomplished because dbnames never have capitals, and python names never have underscores, but it's a rather strict requirement). Otherwise, we'd need an alternate way to know whether a given identifier is in db or python form. I suppose the following mostly works (in shorter pseudo-names): if name != pythonToDB(name) and name != dbToPython(name): ## then we just have to assume something ## as the conversion routines are not 'safe' pass ## or name = pythonToDB(name) if we assume pythonstyle, etc else: if name != pythonToDB(name): name = pythonToDB(name) Part of this question is the same old: do we assume dbstyle or pythonstyle in general? I've always thought of _defaultOrder as specifying a column, so it made sense to have it in pythonstyle (especially now that I can simply redefine my Style object if things change), but I can also see it as similar to _idName or _table, which are dbstyle (but I hopefully see these going away as Styles are used, so...) - Luke |