[Seaside] about roe update issue

[Avi Bryant]

On Mar 28, 2004, at 9:38 PM, danil osipchuk wrote:

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

SQL isn't a very good model of the relational algebra - it certainly 
has industrial usage behind it, but as far as theory goes it's pretty 
messy.  Now, to be useful ROE does have to output good SQL, so it can't 
drift too far, but I don't think taking the path of directly mimicking 
SQL is a good one.  I'll make that stronger: I've tried it, and it's a 
really bad one.  The first incarnation of ROE was SqueakQL, an attempt 
to model SQL in Squeak.  It was a nightmare.  The key insight of ROE 
was that I could get a much simpler and cleaner implementation by going 
back to the relational algebra source and modeling that instead, just 
using SQL as an intermediate language to convey the algebraic 
expressions to the database.

> This is views in SQL are all about and they are not updateable in
> general.

Sure, but what I'm proposing is to do what many databases do: to allow 
updates for the subset of views that are provably reliable to update.  
I don't think that puts us on any shaky ground (whereas the current 
#update: implementation, as I suspected and you discovered, did).

> 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 agree that doing anything with foreign keys, like automatically 
collapsing joins, is another level of framework and should not be in 
the core.  I don't agree that simple updatable views need to be; I 
think the extra simplicity that would bring to the API is worth the 
slight added complexity it adds to the implementation.

However, what's relevant is that you've implemented your way and I 
haven't implemented mine yet :).  Hopefully I'll get something working 
soon and we can properly compare.

>  I think not so many things are waiting for implementation right now  
> to make users (huh, me :)) happy.

Luckily you're the best kind of user: when you need something to make 
you happy, you just add it.  Would that all users were the same... 
(actually, as I'm sure we'd all agree, if all users were even able and 
willing to just articulate what it is that makes them unhappy, that 
would be a major win).  :)

Avi