[Seaside] about roe update issue

Avi Bryant avi at beta4.com
Sat Mar 27 21:29:29 CET 2004


On Mar 27, 2004, at 6:38 AM, danil osipchuk wrote:

> Hello Avi and list
> It seems that trouble with updates is reflection of the fact that
> insert/update/delete operations are not direct subjects of relational
> algebra. These operations in SQL are defined only for tables and I
> think roe should behave in the same way. So if #update will be removed
> from core RARelation and #update: updateBlock where: selectionBlock 
> will
> be added to table relations instead, issue must cease (the same true
> for #delete and #deleteWhere: selectionBlock).

It's good to have a discussion about this, I've been through so many 
iterations and been happy with none of them.  I've probably forgotten 
most of what I liked and didn't like about the various approaches, but 
we can work through it again.

I've certainly never been happy with update the way it works now, 
either, because the SQL it generates is so ugly and inefficient.  The 
NULL problem you found is motivation enough to throw it out.

Looking back through the history you can see that I actually started 
out your way (in v. 28), and then moved to the current method in v. 29 
to support more complex updates (actually, I think I only implemented 
the #update: part, but #update:where: was certainly the plan).  One of 
the things that I didn't like about this at the time is that there's no 
obvious way to bring other tables in on the where clause.  Poking 
around at some SQL documentation, it looks like any extensions that 
allow that (ie UPDATE foo SET ... FROM foo, bar WHERE ...) are 
non-standard anyway, so maybe it's not that big a deal.  How often do 
people need this?

The loss of aliasing, and in general the need to go back to the 
original table object, annoys me more.  One option I know I considered 
but don't think I ever implemented was to use pretty much the same 
public interface that's supported now (ie, #update: and #delete on 
arbitrary relations), but to signal an error if the relation is derived 
from more than one table, or if there are other reasons (like a self 
join, I guess) why it's impossible to construct a simple update query.  
But we should be able to deal fairly simply with any number of 
selections and aliases ok, right?  The aliases can just be replaced 
with the original names, since without joins there's no fear of 
ambiguity, and a series of selections can just be ANDed together into 
one.

Comments?

Avi



More information about the Seaside mailing list