[SQLObject] higher-level types for attributes..

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

Hi Ian,

I suppose I'm bombing you with too much--but the ideas keep flowing
while I work on things...

I was wondering about how to provide higher-level data types for
attributes than just those offered by SQL (corresponding to subclasses
of Col).  If it is already possible, I would like to ask how.  Else,
here are ideas of what could be done:

Two examples to illustrate what I mean by higher-level types:

* (single) home phone number as an attribute in a person table:

(note that this is different from the example in people.py--just can't
think of anything better right now...)

At a low level, they are implemented as a string.  At a higher level,
it may be a class with various constructors etc, with a distinction of
area code and number, etc. and maybe with consistency constraints...

Now in the database, it makes sense to represent it as a single
string, but in the object world, it would be nice if it was an
instance of the class PhoneNumber.  

It would be nice if SQLObject could store something like __rep__
(different from __repr__) in the DBMS but type cast the result (maybe
as does the pickling module?). 


* the coordinates of a location

Assume that--at a low level--I want the latitude and longitude to be
attributes of a city table.  But really, I would like to get them out
together and treat them as instances of the "point" class.  To make it
a table of its own with a 1:1 relationship to city would be rather
awkward...

Since a point adds several fields, this could be considered some kind
of an "inline table".  The columns of this table to be inlined could
be defined by _columns in the appropriate class...

I hope this made it clear what I'm thinking of.  Now some ideas for
the implementation:

For the former case, one of the existing subclasses of Col could be
used to specify the representation type.  An additional keyword
attribute would specify the target class for the value.  For example,
class=PhoneNumber.  The target class would probably have to provide
two functions:  one to "serialize" it to the representation type
(maybe called __rep__ or __sqlRep__), and one to construct an instance
back from that.   Note that any kind of object that you don't want to
be used in SQL queries could be simply pickled to represent...

How difficult would this be to add?  Is this easy to integrate into
caching?  

BTW, I believe to remember that the Gnosis XML package does some
similar type of serialization/unserialization of objects...

For the latter case of "inline tables", a specific subclass of Col may
be appropriate.  It would specify the class to inline--everything else
would be specified there.  

Looking forward to hearing what you think of this.  Also, if you give
me guidance on where to lie hands, I may attempt to try something
out...

best cheers
--bud

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