I don't think having a table without a primary key is a strawman use
case at all, and agree that SA should be able to handle it. I suspect
that a lot of people fall back on just having an 'ID' Integer field and
primary key, which they tend to then totally ignore. I think that's
counterproductive, optimizing for a case that never occurs.
- Ed Suominen
P.S. to Michael and the other SA devs: I am really impressed with this
piece of work you've put together, and the healthy activity surrounding
it is evidence that others feel the same. Thanks!
Rick Morrision wrote:
> Repost: Sorry, posted directly to Micheal instead of the list:
>
>
> FWIW, cursor.lastrowid can be implemented with "SELECT
> currval('seqname')" which will return the correct value without worry of
> race conditions as long as it's done within the same transaction as the
> INSERT id you're looking for and it's a single-row insert.
>
> When the Postgres team implements INSERT ROW RETURNING, this will be a
> better long-term solution, but I don't know if it's even on the list for
> 8.2.
>
> But in the larger question, why is a primary required in all cases?
> What about the hypothetical use case for a table of of a loose
> collection of attributes, where dup records might be OK:
>
> CREATE TABLE cust_notes (
> idcust int not null,
> note text
> );
>
> You mean you can't do an INSERT on this table with SA?
>
> A strawman use case, sure -- but shouldn't we be able to handle it?
>
> Rick
>
>
>
> On 2/17/06, *Michael Bayer* <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> OK, what is the table def exactly ? one limitation about psycopg is
> that sqlalchemy has to be able to pre-execute whatever defaults exist
> for the primary key columns of the table. if you insert a row into a
> postgres table, and some of the primary key columns are None, and
> theres no sequence or anything for it to explicitly execute
> beforehand, relying instead upon some defaults (i.e. PassiveDefaults)
> that fire off within postgres in order to insert the row, it has no
> way of getting back that row if OIDs are turned off. the author of
> psycopg has offered no solution to this and thinks "cursor.lastrowid"
> should basically be removed.
>
> On Feb 16, 2006, at 11:55 PM, Robert Leftwich wrote:
>
>> Michael Bayer wrote:
>>> but there could be bugs. what behavior have you observed ?
>>
>> When inserting rows in a table that has a multi-column primary key
>> defined and the engine is created with use_oid=False, I get back a
>> message "cant use cursor.lastrowid without OIDs enabled".
>>
>> Robert
>>
>>
-------------------------------------------------------
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
