On Jan 29, 2006, at 11:47 AM, Jonathan Ellis wrote:
Trying to guarantee that we know what data will be in the row before it is inserted sounds like a hard problem. The obvious difficulty is triggers, and in PG you have rules as well. So in at least those cases you will have to allow users to mark the table somehow as needing to be re-scanned after an insert/update. This could be generalized to column defaults as well. (If there's a lot of defaults, it could be more efficient to do one post-insert query than several pre-insert ones.)
its totally tricky, since I need to execute the defaults that create primary key columns beforehand, due to the uselessness of cursor.lastrowid with psycopg. there is some postfetch code in there but really doing it suggests that it would have to be generalized across all types of databases to properly post-fetch defaults. I generally like the idea of post-fetching defaults better than pre- executing, if they are executed at the DB level. So I might want to look into, when reflecting the defaults from the database, just putting a flag on the Default "execed_by_db" or something (maybe a PostFetchDefault object), which indicates to postfetch the existing default. that way I dont have to worry as much about the text returned by the infoschema being executable, and databases that dont give me a clear view of db-level defaults can have such a Default object attached to it indicating to just go an get it after an INSERT.
------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Sqlalchemy-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
