For anyone interested in the relational database <---> objects problem you
might want to look at the "Crossing Chasms" pattern language that Kyle Brown
and Bruce Whitenack put together a few years ago.  Try

	
http://members.aol.com/kgb1001001/Articles/ObjectRelational/ObjectRelational
.htm
or
	http://www.ksccary.com/articles.htm

Bob Jarvis
Compuware @ Timken

> -----Original Message-----
> From:	Jerome E. Garcia [SMTP:jerome at lightsurf.com]
> Sent:	Wednesday, February 16, 2000 12:07 PM
> To:	Squeak Mail List
> Subject:	RE: Database connectivity anyone?
> 
> 
> 
> > -----Original Message-----
> > From: David Pennell [mailto:dpennell at quallaby.com]
> > Sent: Wednesday, February 16, 2000 7:17 AM
> > To: squeak at cs.uiuc.edu
> > Subject: RE: Database connectivity anyone?
> >
> 
> > Has anybody got strong feelings about a class library for SQL database
> > access?
> > It seems clear we will end up with multiple databases, if we had a
> little
> > framework,
> > it might be less intimidating to fill in the vendor specific pieces.
> >
> 
> Having encountered this problem before at Claris, I feel pretty strongly
> that two class hierarchies should be provided: a "data provider" hierarchy
> and a "SQL expression" hierarchy. The "data provider" hierarchy should
> provide all access to any kind of data provider such as flat files,
> indexed
> files, relational databases, etc. The "SQL expression" or "database
> request"
> should provide for the creation of expression trees representing database
> requests. If done correctly, these trees can represent requests to various
> providers of data whether they be flat file, relational, or something
> else.
> They could even be requests spanning multiple heterogeneous providers if
> you
> are willing to deal with the join issues.
> 
> Jerome