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
|
