[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