Replying to my own post ...
On Monday, Oct 6, 2003, at 10:50 Europe/Rome, Giulio Cesare Solaroli
wrote:
> [...]
>
> I have though about this during the weekend, and here the outcome of
> my delirium:
>
> - ExpressionEvaluation: an interface that expressions that can be
> evaluate in memory should implement; basically I think the only method
> defined here should be
> public boolean evalWithDataObject(org.objectstyle.cayenne.DataObject
> anObject);
>
> - SQLExpression: an interface to be implemented by expressions that
> can be evaluated as SQL statements; the method defined in this
> interface should be something like:
> public org.objectstyle.cayenne.query.SelectQuery
> queryWithAdapter(org.objectstyle.cayenne.dba.DbAdapter aDbAdapter);
>
> - Expression: an abstract class that could be used as superclass of
> the real expressions, and that could implement many common methods
> useful for the creation of the SQL;
>
> With this arrangement, every expression could be derived by Expression
> and should implement both the ExpressionEvaluation and the
> SQLExpression interfaces. This will allow for expression that could be
> only evaluated in memory and also for expressions that could be only
> evaluated on DB (for example expressions that translates to query
> using special syntax like the INTERMEDIA one, available with Oracle,
> that are not easily emulated in memory).
>
> The method "queryWithAdapter" should use the given adapter to
> customize the SQL generation for any given RDBMS supported; I have not
> figured out exactly how, however. I am not sure even if this method
> should return a SelectQuery or something else entirely, as the
> processes of creating the whole SQL string is not yet cristal clear to
> me, yet.
I think I have found the missing piece.
What was wrong with my suggestion is that no "query context" was kept.
Every Expression could add its piece of statement, but there is a query
wide context that was not represented in my suggestion.
So we could add a new class, SQLQueryContext, that takes care of the
context that grows up while every Expression add its own chunk of SQL
to the final query; the context basically consists of Tables, relative
aliases, and not available aliases (as used by subqueries or similar).
With this arrangement, the queryWithAdapter method should take another
parameter, a SQLQueryContext instance. This object will be passed along
the whole chain of Expression in order to build up the whole context of
the query (basically, the way the FROM clause should be build).
> Anyway, this is still the most troubled point also for other reasons:
> it is easy to factor into DbAdapter (and implement them into the
> subclasses) the differences of SQL syntax for the known situations,
> but it's quite hard to add something afterwards.
>
> What I am missing here is the Objective-C category concept, that will
> allow some methods to be added to a given class, also by an external
> package. :-[
I need to take a closer look to aspect based programming that, if I got
it right, should be the Java answer to the problem solved by Categories
in Objective-C.
Now I feel quite confident that the whole Expression package, with in
memory evalation and SQL generation, could end up in a very elegant
way, with very few code.
Giulio Cesare
This archive was generated by hypermail 2.0.0 : Tue Oct 07 2003 - 04:35:49 EDT