It's essentially an attempt to provide object-database-like functionality, 
but with storage in a relational database. It'll never be as clean or 
direct as a real object database, but it runs against relational so you get 
all the tools, management approval, etc. that go with that. In some 
respects it's more complicated than object databases, which only have to 
handle one representation. Typically object-relational has to be able to 
twist an object model into existing relational models that aren't 
necessarily a good match for it.

For, example, it would support facilities like this (the syntax could be 
more convenient, but you get the idea)
    session beginUnitOfWork.
    query := Query
         returningManyOf: Customer
         where: [:customer | customer address city = 'Ottawa'].
    customers := query executeIn: session.
    customers first orders removeLast.
    session register: (Customer new name: 'Somebody').
    session commitUnitOfWork.

which would read all customers  in Ottawa, delete an order from one, and 
create a new customer. Elsewhere, of course, you would have to describe how 
customers, addresses and orders corresponded to things in the database, but 
that's done declaratively. Currently this is done in code, e.g.

         aDescriptor describedClass: Customer.
         aDescriptor table: (self tableNamed: 'GR_CUSTOMER').
         aDescriptor addMapping: (
                 DirectMapping from: #id to: ((self tableNamed: 
'GR_CUSTOMER') fieldNamed: 'ID')).
         aDescriptor addMapping: (
                 DirectMapping from: #name to: ((self tableNamed: 
'GR_CUSTOMER') fieldNamed: 'NAME')).
         aDescriptor addMapping: (
                 OneToManyMapping new
                         attributeName: #transactions;
                         referenceClass: BankTransaction;
                         mappingCriteria: (PrimaryKeyExpression
                                 from: ((self tableNamed: 'GR_CUSTOMER') 
fieldNamed: 'ID')
                                 to: ((self tableNamed: 'BANK_TRANS') 
fieldNamed: 'OWNER_ID'))).

I don't understand the distinction between being suitable for building 
applications or solving only the persistence issues. It solves the 
persistence issues, and then you would be able to build applications on top 
of that, using those facilities.

At 10:43 PM 7/9/00 -0700, Michael_Chean wrote:
>Question:
>What is the purpose of an object-relational mapping framework?
>Will it be an object database?  Suitable for building applications, or does
>it solve only the persistance issues?
>----- Original Message -----
>From: "Ralph Johnson" <johnson at cs.uiuc.edu>
>To: <squeak at cs.uiuc.edu>
>Sent: Sunday, July 09, 2000 9:03 PM
>Subject: Re: Transactions in Squeak?
>
>
> > See GLORP at http://glorp.sourceforge.net/
> > It is a simple Smalltalk object-relationsl mapping framework
> > that is eventually supposed to be portable to all dialects
> > of Smalltalk.
> >
> > -Ralph
> >

--
Alan Knight [|]
knight at acm.org
ParcPlace division, Cincom