[DB-SIG] Which db mapping tool?

[Andy Todd]

Matthew T. Kromer wrote:
> Federico Di Gregorio wrote:
> 
>> imo, rowid _has_ a different meaning. if you have two serials or more to
>> which does rowid refers? and if you don't have *any* serial? rowid
>> should identify unambiguously (does such a word even exists in english?)
>> a row and the oid does exactly that.
>>
>>  
>>
> 
> The ROWID in Oracle represents an encoded record position in the 
> database.  It is guaranteed to be unique, and also can represent which 
> database (if the server has serveral databases) the record was served 
> out of.  The ROWID is synthetic, I think.  You can usually either query 
> the ROWID explicitly, or it is implicitly returned on queries and can be 
> obtained by an attribute on the statement handle (I think!).
> 

Absolutely correct. The ROWID in Oracle is a pseudo column, just like 
'user' and 'sysdate'. There are assembled by the database at query 
execution and returned just like proper column values. They can be used 
anywhere you would use an actual column name or (in Oracle 8.0 and 
above) a function name.

> I make DCOracle2 return ROWIDS (SQLT_RDD) as an opaque type, albeit one 
> that is useful for looping back around and feeding to Oracle.  example:
> 
>  >>> c.execute('select rowid, name from test where id=43')
> 1
>  >>> r = c.fetchone()
>  >>> print r
> [<OracleRowID at 0x0815ec74>, None]
>  >>> rid = r[0]
>  >>> c.execute('select name, id from test where rowid=:1', rid)
> 1
>  >>> r = c.fetchall()
>  >>> print r
> [[None, 43]]
>  >>>
> 

Absolutely the correct way to handle it. If you want to get boring, the 
rowid is usually four hex numbers (of machine word length) bundled 
together. As soon as you try and convert them to anything else things 
get a little scary, unless ...

> Oracle also has dbms utility functions that can decode the rowid. 
> Mozilla is about to crash on me or I'd show an example (I'll be lucky to 
> send this mail!)
> 

Never used them myself. As a rule of thumb its fine to use ROWID values 
in your SQL but I wouldn't want to have them hanging around anywhere 
else. Of course, your application code will always refer to specific 
rows by their primary key column values, won't it ;-)

Regards,
Andy
-- 
----------------------------------------------------------------------
 From the desk of Andrew J Todd esq - http://www.halfcooked.com