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

[Diedrich Vorberg]

Hi Ross,

>Subject: No such attribute or function 'oid'
Did the patch throw this exception?

>>... Stuff about gpsql and oids

>Yeah, this was the one thing I was thinking about bringing up, though it's
>probably a post-1.0 thing (perhaps not). Oids are now optional on
>user tables, and are not guaranteed to be unique, anyway, unless you add
>a unique index on the column. So this problem will start to bite lots of
>people using regular tables, not just views. My take on it from the orm
>point of view is to use a PrimaryKey wherever it is defined, and only fall
>back to oid if there is no such key. 
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.

>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.

>>    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.

>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 
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?

Diedrich

-- 
           _..._                            Diedrich Vorberg
         .'     '.
        /  _   _  \                         http://www.tux4web.de
        | (o)_(o) |                         info@tux4web.de
         \(     ) /            .---.
         //'._.'\ \           /     \       Internet Dienstleistungen
        //   .   \ \          \.@-@./       und 'Consulting'.
       ||   .     \ \         /`\_/`\
       |\   :     / |        //  _  \\      Linux Rules!
       \ `) '   (`  /_      | \     )|_
     _)``".____,.'"` (_    /`\_`>  <_/ \
     )     )'--'(     (    \__/'---'\__/
      '---`      `---`