gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] proposal for dbapi base class


From: engelbert . gruber
Subject: Re: [Gnumed-devel] proposal for dbapi base class
Date: Mon, 20 Jan 2003 15:22:13 +0100 (CET)

On Tue, 21 Jan 2003, Horst Herb wrote:

> On Mon, 20 Jan 2003 23:50, Karsten Hilbert wrote:
> > > class dbapi:
> >
> > The naming is perhaps a bit unfortunate.
>
> Yes. Was just to illustrate what it is about
>
> > What is this to wrap ? 1:1 onto tables ? In which case
> > it could be named "dbtable".
>
> NOT a table. A concept, like a "patient" which is made up by many tables. The
> whole point of our dbapi is to get away from the table complexity

do i smell an object-relational-mapper here,
or is it an object-relational-mapping ?

means a generic mapper or handcrafted mappings ?

>
> > methods as generic as they are now, eg:
> > >   def fetch(self, pkey):
> > >           """fetch the record as identified by the primary key pkey.
> > >           The record can then be accessed via class attributes"""
> > >           raise PureVirtualFunction
>
> In order to fetch data, you need an unique identifier - the primary key. This
> primary key may or may not be identical with the one of one of the underlying
> tables - but in any case: no fetching without primary key, no matter what you
> do.

in case of a mapper the unique identifier would be an unique-object-identifier,
does gnumed have such a thing (global object_id_generator with method next()
e.g.)

> > The conceptual idea of this method does loose a lot of
> > flexibility as Ian points out.
>
> Why? If you ant the full flexibility, stick to SQL. If you want comfort, use
> the API.

if there is an api, try to stick to it.

-- 
 BINGO: professionally create virtual services
 --- Engelbert Gruber -------+
 SSG Fintl,Gruber,Lassnig   /
 A6410 Telfs Untermarkt 9  /
 Tel. ++43-5262-64727 ----+




reply via email to

[Prev in Thread] Current Thread [Next in Thread]