On 08 May 2003 09:44:21 -0500
Nick <nick@...> wrote:
> On Thu, 2003-05-08 at 04:37, Bud P.Bruegger wrote:
> > Backend:
> > An object that manages the interaction with the actual database.
> > It has the following components:
> > - mapping
> > - dbDriver
> > - dbConnection
>
> Don't forget cache somewhere, which probably makes more sense to put
> here than in the Connection.
Absolutely right!
> > Mapping:
> > Description of the physical representation in a dbms-independent way.
>
> Isn't mapping dependent on the way the data is stored in the database?
> Maybe I'm misunderstanding what you mean by mapping.
Yes, the mapping describes how objects are stored in the dbms but
abstracts from the details that differ with the actually used dbms
(mysql, postgres, etc).
> > 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.
>
> How does this relate to mapping? It sounds similar.
It's a component, have a look at the UML class diagram that I
attached..
Thanks for the feedback
--b

On Thu, 2003-05-08 at 04:37, Bud P.Bruegger wrote:
> Backend:
> An object that manages the interaction with the actual database.
> It has the following components:
> - mapping
> - dbDriver
> - dbConnection
Don't forget cache somewhere, which probably makes more sense to put
here than in the Connection.
> Mapping:
> Description of the physical representation in a dbms-independent way.
Isn't mapping dependent on the way the data is stored in the database?
Maybe I'm misunderstanding what you mean by mapping.
> 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.
How does this relate to mapping? It sounds similar.
Nick

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)
\-----------------------------------------------------------------