Okay, some revisions to the idea but we're getting somewhere, which is cool.

> http://www.postgresql.org/docs/8.2/static/sql-prepare.html
Oleg! Mahlohdetz! Good catch on the table generation time with postgres
limitation!  I guess we're stuck with a non-automated version of this, which
requires (building on the previous ideas):

class DumbTable(SQLObject):
    class sqlmeta:
        idName          = 'dumbTableID'
        table           = 'dumbTable'

    firstField = NumericCol(dbName='amount')

    def __init__(self):
        self.createPreppedGetByIDStatement()
        #... Make a call to Sqlobject's __init__()??

    def createPreppedGetByIDStatement(self):
        return '''prepare SQLObject_dumbTable_getByID (int) 
            as select firstField from dumbTable where dumbTableID = $1'''

    def executePreppedGetByIDStatement(self, id):
        return '''execute SQLObject_dumbTable_getByID (id)'''


t = createTransaction()
# throw away first call to DumbTable, just populate this 
# transaction/connection with a prepared getbyid.  Now, use it:
dt = DumbTable(connection=t).createPreppedGetByIDStatement()
# now do whatever, presume OtherTable has a foreign 
# key reference to dumb table id = 2
ff = otherTable.dumbTable.firstField
# This ff assignment should generate a call to 
# dt.executePreppedGetByIDStatement(2) if it exists, and 
# otherwise do it the old fashioned way.

Catch my drift?  Is this silly?  I'm thinking that if there's low overhead
on calling back to the object's executePrepped...() method, then there's no
downside to making these calls often, but it could be lots faster in the
common case of a non-cached join.

-- Kevin
___________________________________
Kevin J. Rice
Senior Software Engineer, Textura LLC
51-K Sherwood Terrace, Lake Bluff IL  
(847) 235-8437 (spells VISAFLUIDS)
(847) 845-7423 (845-RICE, cellphone)
___________________________________


-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Oleg
Broytmann
Sent: Thursday, August 30, 2007 2:59 PM
To: sqlobject-discuss@lists.sourceforge.net
Subject: Re: [SQLObject] Attempt at Implementing Bound Params
inSQLObjectforget-by-id calls

On Thu, Aug 30, 2007 at 02:49:26PM -0500, Kevin J. Rice wrote:
> Two options present themselves: (a) A get-by-id prepare could be run 
> at table generation time.

   You cannot do that.
http://www.postgresql.org/docs/8.2/static/sql-prepare.html
   "Prepared statements only last for the duration of the current database
session. When the session ends, the prepared statement is forgotten, so it
must be recreated before being used again. This also means that a single
prepared statement cannot be used by multiple simultaneous database clients;
however, each client can create their own prepared statement to use."

> 2.  Is there agreement that there would be significant performance 
> gain with it?

   There could be no agreement. But you might show us there is a gain.

> Among the user community, has anyone else turned on SQL debug and 
> watched all the "select where.. Id=22" stuff goes by and wondered if 
> we could speed this part up?

   Yes, I had asked the question myself. And answered it by using SQL*Joins
;)

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            [EMAIL PROTECTED]
           Programmers don't die, they just GOSUB without RETURN.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
sqlobject-discuss mailing list
sqlobject-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
sqlobject-discuss mailing list
sqlobject-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss

Reply via email to