[DB-SIG] ping method for connection objects

Michael C. Neel neel@mediapulse.com
Wed, 9 Oct 2002 14:16:04 -0400


Inline...

>"select 1" is not portable. It is also not clear that the driver
>will actually check the network connection that way.

Would it have to be portable?  A driver would know if it's database had
a true connection test method, or know if select 1 would work correctly
or not.  The gem of a .ping method is the user doesn't have to worry
about how to test a connection, or about changing that method should the
database change.

>If you'd like a .ping() method on connections, I could add it
>as standard extension to the spec, but I doubt that it will get
>implemented by many interface authors.

>A .reconnect() method would not be in line with the spec (once
>you close a connection it becomes useless). But that's easy to
>handle by a connect wrapper function, if you need it.

The main reason to have a reconnect method is to allow the current
object to be reused.  You'll have to forgive me on the following
example, as I'm still somewhat new to the deeper parts of python, so
this may not work like I outline.  Take a python script and connect to
the database, then pass the db object to two other child objects.  Child
A notices that the db handle has gone stale, and reconnects the normal
way, with another call to create a new object.  Child B never knows
about this, because that new object would be in A's space.  In C I could
share a pointer to get around this, C++ pass by reference, and there may
be some options in python as well.  plus, it would simplify handle
testing code across all drivers down to:

if !db.ping():
	db.reconnect()=20

Reconnecting would not need to know hostname, username, password, etc;
it would just use whatever was set in the connect statement.

>Please remember that the DB API focuses on the low-level
>aspects of talking to databases, not the more involved issues
>like connection pooling, automatic reconnect, schema analysis
>or even object-relational mappings. That's left for layers on top
>of the DB API to implement.

I would even go so far as to say some of these things should be looked
at for a 3.0 spec.  Pooling is something that has to be done quite
often, and having it driver level makes sense.  A few options to the
connect statement could set this up for the user.  Automatic reconnect
could also be some with connect options.

Is that traditional db driver-like?  No, but I don't think that should
have any bearing on the matter.  We (programmers) should be looking to
new languages to simplify our life, not recreate old interfaces in new
syntax.  Laziness, Impatience, Hubris - Larry Wall and perl isn't all
bad!

Mike
--
Michael C. Neel
There are only 10 types of people in the world;
those who understand binary and those who don't.