Re: [SQLObject] naming conventions

This gets to a current struggle in SQLObject over whether to name
things by SQL convention or Python convention. It's split right now,
but for instance:

notNull vs notNone
TextCol/CharCol vs StringCol

I think Ian recently changed his mind to go with notNull, but was
opposed to TextCol still (sorry if I'm misquoting you, Ian). My
personal opinion is that anything that describes the database
(notNull) should be in database-speak, otherwise it should be python.
Columns are a little harder, as they cross bewteen the two;
Constraints also muddy this (should it be TimestampCol, with a
validDateTime constraint?)

Consistency may be hard to come by. Perhaps my preference would be to
support both, with TimestampCol being an alias to DateTimeCol, and
TextCol being a mostly-transparent subclass of StringCol.

- Luke

Quoting Nick <ni...@dd...>:

> Okay, correct me if I'm wrong here, but isn't the ANSI standard for
> storing ISO dates in a database using a TIMESTAMP type?  I'm pretty
> sure
> it is... so why is the column type in SQLObject DateTimeCol instead
> of
> TimestampCol?  I realize that each database backend uses its own
> type,
> but shouldn't SQLObject's naming stick to the standards?
>
> Hoping not to start a db holy war,
> Nick