[TransWarp] RFC: DM SPI change

[Phillip J. Eby]

At 10:55 PM 1/16/03 +0100, Geert-Jan Van den Bogaerde wrote:
>On Thu, 2003-01-16 at 18:28, Phillip J. Eby wrote:
> > At 06:13 PM 1/16/03 +0100, Geert-Jan Van den Bogaerde wrote:
> >
> > >By the way, is there a specific recommended strategy for mapping a
> > >rather extensive class hierarchy (i.e., one with a rather deep
> > >inheritance graph) of PEAK domain elements to an SQL database?
> >
> > There is a paper out there that describes many patterns of mapping, and
> > each is useful for a certain kind of model and application.  Our bias is
> > towards a "table per interface" approach, but there are many others 
> such as
> > table per class and table per class family.  Unfortunately the name of the
> > paper escapes me at the moment.
> >
> > PEAK was intended to support arbitrary mappings, however, to SQL and any
> > other type of data storage or object implementation, because we have the
> > need to create object models over legacy databases whose schemas we cannot
> > control or dictate.  So, use whatever suits your application.
>
>Whoops! I had meant to send this to the list, just the hit the wrong button.
>Thanks for the reply, though. Would the paper you refer to be
>http://www.agiledata.org/essays/mappingObjects.html by Scott Ambler? He 
>also wrote
>another paper on object persistence layers that I've read before and found 
>quite
>interesting.

I'm not sure, it has been many years since I read the paper, but that might 
have been the one.


>I've written some ad hoc solutions for this type of thing before, but never a
>full-blown persistence layer as I've never had to write what one would call
>"enterprise"-level applications. I'm looking forward to immersing myself 
>in the
>subject, and PEAK looks like an excellent way to start :-)

Luckily, PEAK actually handles most of the pure "persistence layer" issues 
for you.  It just doesn't deal with the "persistence mapping" part, leaving 
that for you to fill in.  I expect it will eventually have some kind of 
mapping framework, but it will probably be specific to our WarpCORE 
database design patterns, since they should end up with relatively 
straightforward mappings to and from peak.model.