[orm-devel] No such attribute or function 'oid'

[Ross J. Reedstrom]

On Mon, Jan 13, 2003 at 05:44:20PM +0100, Diedrich Vorberg wrote:
> Hi Ross,
> 
> >Subject: No such attribute or function 'oid'
> Did the patch throw this exception?

Didn't try it. BTW, I wasn't the original poster on this, you know. That
was Eric Walstad.

> >>... Stuff about gpsql and oids
> 
> The reason I kept the special treatment of oids is rather 
> 'traditional' than practical: oids and the idea of an "object 
> relational database" inspired orm in the first place. Also the 
> predecessor of orm depended on oids entirely (which turned out to be 
> one of my worst ideas for it, because you couldn't easily backup :-). 
> I wanted to make orm downward-compatible.

Well ,the problem is that right now oids are deprecated, but thier correct
replacements are really ready. For example, the wire protocol actually 
provides the OID of a newly inserted tuple, for free. Getting anything
else requires an extra round trip to the DB. This is an extra pain when
the primary key is a backend generated serial.

> >This gets complicated when the pkey
> >is compound: more than one column. One answer would be not to support
> >such tables.
> I will have to think about this. It might not be too difficult. Could
> you send me with a real world example in SQL? The primary key could be
> a python tuple.

So, probably not a big problem,as you see it. That'd be good.

> >>    http://mailman.tux4web.de/pipermail/orm-devel/2002-November/000013.html
> >> which contains a patch to adapters.pgsql.datasource that you might
> >To be honest, I didn't dig into this patch, since it seemed to me that
> >the right solution is not to distinguish between table and view, but
> >rather with and without oids. 
> Since there is no reason to keep this compatibility I could make a 
> column type oid() which provides the old functionality but is optional 
> for the dbclasses. This way a view would be a regular dbclass with 
> its tablename attribute set to "table0, table1" this should work fine.

Hmm, not sure about the strange tablename your suggesting. Let me lecture
a bit on views.

>From the client's perspective, a view is merely a readonly table. The
details of how it's implemented are that the original query is rewritten
to access the actual tables, like so:

Given tables:

CREATE TABLE people (peid serial NOT NULL PRIMARY KEY, name text);
CRATE TABLE people_phone (peid int, phoneid int)
CREATE TABLE phone  (phoneid serial NOT NULL PRIMARY KEY, 
                     number text, type text);

CREATE VIEW phonebook AS 
SELECT name,number,type FROM people p,people_phone pp, phones f WHERE 
  p.phoneid = pp.phoneid AND pp.phoneid = f.phoneid;

Now:

SELECT * from phonebook order by name,type;

will yield something like:

     name       |    number    | type
----------------+--------------+-----
Duck, Donald    | 589-555-7825 | home
Reedstrom, Ross | 713-555-1234 | cell
Reedstrom, Ross | 713-555-1212 | home
Reedstrom, Ross | 713-348-6166 | office

What really happened is that the query was expanded by the view
definition, sort of like a macro.

But as far as the client is concerned, that's a real table, except for:

> >And views are _always_ readonly: you can make them writeable with
> >some extra ON INSERT and ON UPDATE rules.
> Do you mean they are _not_ always readonly? Should this be treated by 

Right, _not_ always.

> orm? This could be done with relative ease: I'm thinking of a 
> childclass of dbclass for views which overloads the insertCommand() 
> method so that it returns an appropriate SQL statement for inserting 
> into a view. Do read/write views make sense at all or should they 
> rather be avoided?

In some circumstances, read/write views are the only way to go. I think
someone's workng on readonly tables, as well, right now. From orm's point
of view, rather than implementing the writing in the middleware, we just
need to support tables that throw errors on writing. Or, we could require
the coder to specify that this is a readonly table (usual case, a regular
view) which would then not need to implement all the write support for the
mirror class.

What do you think of that?

Ross