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