[SQLObject] thoughts on structure and components

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

Hi everyone,

Been thinking these days and would like to share some of what I came
up with.  I suppose this could be of interest just for academic
purposes or for a possible future refactoring of SQLObject.  If it's
not of interest, just ignore.  

My thinking was triggered by:
- My wish for higher-level physical types that users construct
  depending on the application
- My difficulties to easily add the things to SQLObject that I
  expected to be easy:  e.g., foreign keys...
- I have an intuition (that I cannot materialize) that there is some
  strong coupling in SqlObject that steepens the learning curve and
  makes some behavior unintuitive.  It may be that also the issues of
  difficulties of subclassing etc. are falling in this area...  As I
  said, I have no overly clear ideas to offer.  

So my first product out of this is just a clarification of what
concepts (classes) there should be and how they relate with each
other.  A first rough writeup of my ideas follows here:

Concepts:
---------

Application Object:
  An Application Object is independent of backend storage

Storable:
  A superclass that makes application objects storable.  
  It adds methods that interact with the Backend in order to
  - store
  - update
  - delete
  the object
  In addition, it provided methods to easily access related objects

Backend:
  An object that manages the interaction with the actual database.
  It has the following components:
  - mapping
  - dbDriver
  - dbConnection
  A first version can live with a single driver and connection--a later
  version may be able to work with multiple databases

Connection:
  An actual connection or connection pool that interacts with the dbms

DBdriver:
  A class that provides functionality that depends on the kind of connection
  used, typically depending on:
  - dbms used (e.g., postgres)
  - DBI module (and version)
  The DBdriver supports a subset of dbCols

Mapping:
  Description of the physical representation in a dbms-independent way.  
  The mapping is described by the following components:
  - Attributes of Storable Objects
  - Relationships of Storable Objects

DbCol:  
  A low level physical type to represent a single field in the dbms. It is an
  abstraction of the actual SQL type since different DBdrivers can map it to
  different SQL expressions.  The types are named closely to standard SQL.
  Types such as TIMESTAMP could for example be translated to DateTime by a
  mySQL dbDriver.  

Attribute:
  A high-level physical type to represent the higher-level physical rep.  This
  includes marshalling to and from a lower-level representation.  Marshalling
  can do things such as encoding structured objects (phone number with country
  and area code) to strings, pickling, mapping a single attribute (a point) to
  multiple columns (x, y or lat,long), etc.  

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