Re: [SQLObject] ADO DB-API support?

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

On Tue, 27 May 2003 09:43:25 +0200
Magnus Lyckå <ma...@th...> wrote:

> I think the db driver should look for a standardized attribute in
> each parameter it gets, and if it finds it, it should call it as
> a method, and then recieve a string which is the representation
> of data that we want to send, and a description of what type it
> should become in the backend. I think this combo is needed.
> 
> If it gets '123' and DECIMAL it knows that it should replace the
> ? with 123, but if it gets '123' and VARCHAR it should replace ?
> with '123'. I haven't tried to implement that though.

The issue of types and marshalling in DB-API modules is definitely an
interesting one.  I see it as more complex than what you describe
above.  It is really that of type-casting that goes in both
directions, to and from the db.  Some DB-API modules (eg, psycopg)
seem to support user-defined type-casts.  But that is not standardized
and I believe that psycopg's casting support is currently being
redesigned and rewritten.

So since this was too terse to be understandable, here an explanation.

In python, arguments are of given types.  Types are the same as
classes, ie. encapsulated state and behavior.  There is no
restriction of what types there are since users usually define their
own.  

In contrast, in the dbms, types are restricted to "basic types" for
which state is definitely in the foreground and behavior is secondary.  

Any kind of middleware has to bridge the conceptual gap by
marshalling/unmarshalling or type-casting (or whatever you call it).  

Marshalling gets from a python attribute to (in general) a number of
db columns of simple type.  In other words, it maps the encapsulated
state to a list of simple types.  

Unmarshalling converts a list of simple types into an object of the
given type with reconstructed state (and obviously, all the behavior).

In my understanding, the solution you line out above is only partial.
It supports marshalling to a single db column.  But it does not seem
to support the unmarshalling, ie., casting the column back to the
original python type.  

Here an example that illustrates this more:

Assume we have an attribute of type "Location" that is a class with
behavior such as "distance" or "containedInPolyon" and is physically
represented by a tuple of numbers (such as lat/long, or UTM northing,
UTM easting).  

Marshalling would then take a single location attribute to two columns
(eg., lat and long) and unmarshalling would reconstruct a Location
instance from a pair of coordinate values.  

While DB-API's support some base types, there is no way they can
support all possible types since they are user defined and cannot be
enumerated.  

So in my understanding, any middleware solution that supports the
general case, needs to have a layer that marshals between python
classes and tuples of basic values.  

Ian and I have discussed this kind of additional layer (that is
currently lacking in SQLObject) earlier under the subject
"higher-level types".  

If you are interested in (much more) detail on this, I can send you
some experimental code (or alpha quality code) that does this for
single objects without relationship.  

cheers
--b



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