sqlobject-discuss

[SQLObject] naming conventions

[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

Re: [SQLObject] naming conventions

[Bud P. B. <bu...@si...>]

That would probably be consistent.  I wasn't disturbed by the name
earlier because DateTime could as well refer to the mx.DateTime type
of python that is stored as the (non-standard) MySQL DateTime data
type...

--b

On 30 Apr 2003 11:53:28 -0500
Nick <ni...@dd...> wrote:

> 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
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
> 


/-----------------------------------------------------------------
| Bud P. Bruegger, Ph.D. 
| Sistema (www.sistema.it)
| Via U. Bassi, 54
| 58100 Grosseto, Italy
| +39-0564-411682 (voice and fax)
\-----------------------------------------------------------------

Re: [SQLObject] naming conventions

[Luke O. <lu...@me...>]

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

Re: [SQLObject] naming conventions

[Nick <ni...@dd...>]

I'll buy that... that's also what psycopg returns.  So, should the
naming be in accordance with Python types or with SQL types?

Nick

On Wed, 2003-04-30 at 12:06, Bud P.Bruegger wrote:
> That would probably be consistent.  I wasn't disturbed by the name
> earlier because DateTime could as well refer to the mx.DateTime type
> of python that is stored as the (non-standard) MySQL DateTime data
> type...
> 
> On 30 Apr 2003 11:53:28 -0500
> Nick <ni...@dd...> wrote:
> > why is the column type in SQLObject DateTimeCol instead of
> > TimestampCol?

Re: [SQLObject] naming conventions

[Bud P. B. <bu...@si...>]

On 30 Apr 2003 12:29:01 -0500
Nick <ni...@dd...> wrote:

> I'll buy that... that's also what psycopg returns.  So, should the
> naming be in accordance with Python types or with SQL types?

I think with SQL types.  After all, the decisions about the best
physical representation of python types cannot be made automatically
(there are many options...).  So there seems no way of avoiding to
deal with SQL. 

[Is this true?  I adapted this conviction from lower-level languages
that require more decisions on physical representation than Python]

There is some friction with this approach tough:

* expressing decisions in SQL terminology is not natural for non-SQL
  backends

* sticking to standard SQL terminology is not natural with
  non-standard SQL dbms...


--b

Re: [SQLObject] naming conventions

[Nick <ni...@dd...>]

On Wed, 2003-04-30 at 12:46, Bud P.Bruegger wrote:
> There is some friction with this approach tough:
> 
> * expressing decisions in SQL terminology is not natural for non-SQL
>   backends
> 
> * sticking to standard SQL terminology is not natural with
>   non-standard SQL dbms...

Although, the class *is* called SQLObject, not DBObject :)

Nick

Re: [SQLObject] naming conventions

[Ian B. <ia...@co...>]

On Wed, 2003-04-30 at 12:11, Luke Opperman wrote:
> 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

Yeah, it's notNull now, but if I stick with Python types it should
really be notNone (which isn't bad, actually).  Maybe I'll make that
change before 0.4.

I'm not sold on using Python types, though I suspect there will be more
confusion if I use SQL types (like DateTimeCol in MySQL, vs.
TimestampCol in Postgres).  We can all agree on the Python types,
because there's only one Python, but there's many databases, not all of
which adhere to the SQL standard (DBMConnection obviously does not, for
instance, nor would MetaKit).

  Ian

Re: [SQLObject] naming conventions

[Ian B. <ia...@co...>]

On Wed, 2003-04-30 at 15:49, Ian Bicking wrote:
> I'm not sold on using Python types, though I suspect there will be more
> confusion if I use SQL types (like DateTimeCol in MySQL, vs.
> TimestampCol in Postgres).  We can all agree on the Python types,
> because there's only one Python, but there's many databases, not all of
> which adhere to the SQL standard (DBMConnection obviously does not, for
> instance, nor would MetaKit).

I'm now feeling more convinced that I should stick to using Python type
names, not SQL names.  In particular, I've been working on this form
stuff, and handling situations where I'm translating from HTTP variables
(i.e., strings) to Python types.  A lot of the same concepts apply to
getting data from SQL, or XMLRPC -- so I'd like for their to be one way
of specifying the type/constraint information.  Python is the only
option, since it's the one thing all the data sources have in common --
the Python destination.

  Ian

Re: [SQLObject] naming conventions

[David M. C. <da...@da...>]

On Wed, Apr 30, 2003 at 12:11:01PM -0500, Luke Opperman wrote:

> 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;

I think Cols should have an attribute for database-specific type (if
available).  This allows querying for a database type that may be
significant to your UI, though not having a meaning in Python or not yet
being handled by a constraint/validation system.

Dave Cook

Re: [SQLObject] naming conventions

[Ian B. <ia...@co...>]

On Wed, 2003-04-30 at 23:34, David M. Cook wrote:
> I think Cols should have an attribute for database-specific type (if
> available).  This allows querying for a database type that may be
> significant to your UI, though not having a meaning in Python or not yet
> being handled by a constraint/validation system.

Sure.  There's now a sqlType keyword argument to Col that should do the
trick. 

  Ian