[Chicago] web2py 1.20 is out

[Martin Maney]

On Tue, Feb 05, 2008 at 02:39:43PM -0600, Massimo Di Pierro wrote:
> > assume that every table has an auto-incrementing int called "id"
> 
> It is easy to ALTER + UPDATE any existing database to be compliant.

Not really - it's not just adding an autoincrement serial number, it's
making that the primary key.  An existing database is likely to have
other users than the web app - that's why it existed before the web app
came along, after all.  :-)  (at least that's what you'd have to do in
Django, though it would allow use of a real key as long as it is a
single column; as best I recall that would also be true in other of the
ORMs I've looked at as well)

> Some people think that the job of a framework should let developer do  
> everything. Other people think that the framework should try to force  
> the developer to follow good practice.

And they're both right, from their own points of view.  As are all the
other views of the elephant named Framework.  Hence the multiplicity of
frameworks (and if one wanted to beat the drum, one could probably make
out that Rails' domination of the Ruby web framework ecosphere is
rather the opposite of an endorsement of Ruby as the greatest language
to come along for web development - really wide use would lead instead
to multiple frameworks with different emphases, as seen in other
languages.  Python, of course, has peculiarly many, but I believe Perl
has more than a couple, and even PHP, although the latter runs more to
gutting whole apps, or plugging things in, I think.)

> I believe it is good practice for DB tables to have a unique  
> autoincrement id field and that is why web2py requires it. This  
> "limitation" make the table portable across multiple back-end databases.

Like most things, it's a tradeoff.  Redundant surrogate keys tend to
confuse things when there's an obvious, meaningful key (this may not be
usual for data sets designed using such a framework, but is that
inherent in the problems being solved or is it just the usual result of
having a hammer, hence approaching everything as if it were a nail?). 
They do, as you say, ease the migration to another, differently
non-compliant database, at least so far as the serial number key goes. 
What is inarguable is that making the framework's ORM require a simple
serial number on every table makes the framework's implementation easier.

-- 
Minsky's Organism Principle: When a system evolves to become more complex,
this always involves a compromise: if its parts become too separate,
then the system's abilities will be limited; but if there are too many
interconnections, then each change in one part will disrupt many others.