[DB-SIG] WHat's the status of DB modules and datetime.py supp ort?

[Kevin Jacobs]

On Mon, 5 Jan 2004, Jon Franz wrote:
> >
> > So I'm not really against the goals of your proposal, per se.  I'd just
> > prefer to start off simple, gain more experience with how these
> > enhancements play out in real code (of which I have more than enough
> > of), and only then contemplate adding more layers of functionality
> > (evolution, not revolution). Better (more precise) type objects are a
> > logical next step, followed by generic type mapping interface, followed
> > by more complex things like you and Frederico are proposing
> > (standardized type constructors and exposed literal escaping APIs).
> >
> > How does this sound?
> 
> It sounds pretty good - but if you remove the cross database aspect
> Fredrico (and myself) would like, you could mandate the type_codes and
> interfaces and let the implementations be DB specific.

I'm not sure I follow you here.  I'm proposing an extension of the two
existing levels of type information provided by DB-API:

  1) type_code, which typically represents some backend specific
     value/cookie that identifies the native storage type.

  2) type objects: e.g., STRING, BINARY, NUMBER, etc.  These objects
     currently include functionality to match type_codes to type objects.

>From native type_codes, it is fairly easy to write a function to obtain a
type objects.  It is not easy, nor commonly useful, to map a type object to
a type code, since the mapping is usually not unique.  I like having native
type_codes, since that is (usually) totally unambiguous and useful for my
own type mapping extensions.

> In this way, you keep the module author's lives (reletivaly) simple while
> adding benefit for the users.  I know, I know, its down the line in what
> you're talking about - but I just want to keep the goal in sight.  I think
> merging the type_code from output with the extended input types (you had a
> good list), even if interfaces are not defined to Do anything with the
> information, would be another good step.  That way, you could move from DB
> to DB and the type_ids would at least be the same (for similar columns),
> reducing the burdon on the users.

In my view, what you want can be accomplished by a helper routine.  So
instead of using the code_code in the description directly as a type
constructor, one could call a function, say, getTypeConstructor(type_code).
Or, if you really want syntactic sugar, one could define a type_code object
that includes __call__ method that "does the right thing".  Unfortunately,
"the right thing" is frequently not so simple.

-Kevin

-- 
--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (440) 871-6725 x 19         E-mail: jacobs at theopalgroup.com
Fax:   (440) 871-6722              WWW:    http://www.theopalgroup.com/