Re: [SQLObject] higher-level types for attributes..

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

On Thu, 2003-04-10 at 11:42, Bud P.Bruegger wrote:
> 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?). 

Right now you'll have to do method overloading, somewhat like the
example in the docs.  In the future the Constraints code should also
make conversion possible, so you'll be able to use that to construct the
phone number object out of the database string (and vice versa).

> * 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...

Hmmm... I'm not clear here.  You mean that the fields have subfields,
like some_table.some_point.x ?  You could add something to SQLBuilder to
use this in queries fairly easily.  For actual retrieval, it's up to
either some (not-yet-implemented) Constraint system to handle it, or the
database adapter.  And the sqlRepr method I mentioned in the other
email.

  Ian