---------- Forwarded message ----------
From: Rick Morrision < [EMAIL PROTECTED]>
Date: Feb 17, 2006 1:30 PM
Subject: Re: [Sqlalchemy-users] Postgres and OID
To: Michael Bayer <[EMAIL PROTECTED]>
Well, agreed from a "pure" ORM standpoint.
But I had planned, and I get the feeling from some of the listserv archive messages that others are planning, on instead using what might be called the "middle" layer of SA not as a strict ORM, but rather as a programmatic interface to various SQL engines.
I plan on using it that way primarily for a certain degree of database independance, so that my app can run against PG, Oracle and MSSQL with a minimal set of changes. To me, the ability to use the mapper API is just frosting on the cake.
Others might use the middle layer for other reasons, maybe just because they like manipulating the DB in Python, rather than SQL.
Anyway, those of us who plan on using SA in this fashion are going to want to continue to have a fairly precise level of control over the data model, which will probably include "bad" things like tables w/o primary keys. If that precludes the ability to use these tables from the ORM mapper, then so be it, but the line should be drawn at the mapper layer, not at the lower-level layer.
Rick
On 2/17/06, Michael Bayer <[EMAIL PROTECTED]
> wrote:
On Feb 17, 2006, at 12:04 PM, Ed Suominen wrote:
> 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.
i think its a rarer case than you think if you are mapping objects to
rows (or creating relationships)...primary keys are really, really
important. i couldnt imagine a schema that didnt have them for every
represented concept (which Id want to use....).
