[Seaside] about roe update issue

danil osipchuk danil at tsnet.ru
Mon Mar 29 07:52:31 CEST 2004


Sorry,
posting to list too (what is correct way to reply here?)


Avi Bryant wrote:

 > 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).

Idea to look into history visited me just after I have submitted the 
post. Certainly, it is naive a bit to think that you didn't look in that 
direction. At first I thought that initial intention was design-driven 
(to provide some common interface for all relations). Now I'm probably 
missing some important point about what roe is.

If goal of roe is to bring relational algebra right here, to smalltalk, 
then the most straightforward way of implementation is to follow SQL 
(with all theory and industrial usage behind it) precisely. After all, 
SQL is proven to be complete implementation of relational algebra and 
roe I hope wants to be too. And the later relies on the former. Ideally, 
there should be no gap (and problems!) between them. If something 
usefull can exist in this area it must be allready there, in SQL.

 > 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?


I think not very often, but if needed something like 
#update:attributesNamed:in: can be implemented, just like in SQL again.

 > 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.


This is views in SQL are all about and they are not updateable in
general. Personaly, I would like to see roe (at least it's core) as 
unshakeable ground with full sql power and simplicity. On such base more 
complex frameworks (like mappers) can be built. One of the ways to get 
what you want is to define #asUpdateableView which will try to generate 
some smart ConcreteRelation tracking aliases and collapsing sequencies 
of selects (and discover some info about references and keys to make 
some of joins work). But this would be another level of framework. I 
think not so many things are waiting for implementation right now  to 
make users (huh, me :)) happy.
What I'm missing?



More information about the Seaside mailing list