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
