> Given all my comments (please, comment on them), if we managed to
> agree on my position that separating data from logic (like in the
> Expression, ExpressionEval, QueryTranslator case) is a bad think, I
> would propose the following path:
>
> - create a new cayenne.qualifiers (can you see how much I am biased?!
> :-] );
> - add all relevant methods to DataContext to be able to use
> qualifiers, still keeping Expressions working;
> - if everything works fine, we could start deprecating Expressions,
> with all the related classes and methods, and move up for a 2.0
> release!! ;-]
>
> This path seems long, but I don't think it will take too much. All
> other Cayenne features should be easily update where needed to use the
> new package.
>
> Needless to say, I will be pleased to start writing this new package,
> even if I will need much help in understanding how to integrate will
> all other Cayenne classes.
>
> Does this make any sense?
I am not taking any offense at constructive criticism. I can produce
badly designed stuff just like the guy next to me :-) In fact the
original Expressions design was done by another Cayenne committer,
Andriy (who is also the author of arguably most complicated piece in
Cayenne - graph sorting of database operations on commit - we are way
ahead of EOF here). Anyway, this original design had a nested class
hierarchy for expressions (operations vs. conditions vs...). It was an
explosion of inner classes, and after some time I replaced it with the
current package, for simplicity sake. He might have been on the right
track, not me .... so lets continue this discussion.
I take the point that having expressions defined as data structures
with no behavior is bad for further extending. I most definitely agree
that ExpressionEval must be merged into expressions, making this part
of expression's behavior. But you still have to convince me that
translation to SQL must be done. My argument is that there must be a
horizontal layer separation, so there is a need of some sort of
external translation mechanism...
E.g. take a look at DB2QualifierTranslator. SQL generated for the LIKE
expression is quiet different from any other database. At the same
time, like EOF, Cayenne would support parallel work with multiple
databases... So the user creating an expression in his code should be
able to run the same query against DB2 and Oracle without rebuilding
the expression....
So whatever design we come up with should address the issue of
customizing SQL generation per RDBMS flavor, given a generic
db-independent expression.
> As you can see yourself, with this arrangement you are forced of
> thinking about all possible cases upfront. To me this is a relevant
> sign of bad design.
If we are to start rewriting expressions package from scratch, I'd
still vote for having an upfront design of such package presented on
this list, before we start an XP-style coding of it ;-).
Also, there are quiet a few existing expression packages (e.g. OGNL:
http://www.ognl.org/ )... I wonder if we can integrate one of those.
This is just something that came to my mind recently... I don't know if
this is a viable idea.
Andrus
This archive was generated by hypermail 2.0.0 : Fri Oct 03 2003 - 16:15:15 EDT