[orm-devel] Updates in one UPDATE statement

Mike Watkins mw@mikewatkins.net
Mon, 18 Nov 2002 08:58:05 -0800 (PST)

repost - oops, forgot to cc this to the list.

Diedrich Vorberg said:
> again I can see the point in that being usefull but I don't like the
idea of having a special method for it, because it would spoil the
impression of orm being transperent. What I tought of is this: we could
use the __del__ special method of every dbclass which gets called just
before the class is garbage collected. This way one UPDATE query could
be sent to the database. The problem is, that you'd have  to keep this
in mind all the time. It is so subtle a thing it is
> likely to cause a great deal of confusion.

What if dbclass had a property which allowed a developer to override the
default behaviour? The 'default' being transparent, as it is now, and the
optional behaviour being "don't issue update statements", forcing the
developer to call a .save() or .commit() method on the object itself?

Then you get the best of both worlds - simple to use transparent
persistence to the db by default, but an ability to tune the behaviour for
situations that warrant it.

For applications with lots of updates this would be pretty useful -
otherwise its possible we may see scalability issues.

It would also save developers from being tempted to call
_conn.cursor.execute directly (guilty already!)