Background:
----------
I am looking at the way to implement "parametrized" expressions. Kind of
like in EOF or TopLink, parametrized expressions are expressions that have
placeholders instead of real values. Later such expressions can be used as
a prototype for the real expression, substituting placeholders with a map
of values.
One thing that was giving me grief when implementing that, was pruning
uninitialized subtrees from the final expression. I am still working on
this, none of the code is checked in.
Current Changes:
---------------
AND and OR expressions were implemented as binary expressions which is
formally correct but made the feature above hard to implement. Also
"binary" implementation generated ugly SQL with lots of nested parenthesis:
...WHERE ((((t0.ARTIST_NAME = ?))) OR (t0.ARTIST_NAME = ?))) OR
(t0.ARTIST_NAME = ?)) OR (t0.ARTIST_NAME = ?)
I created a new type of expressions, ListExpressions, that have an
unspecified number of parameters, each joined with its neighbor using the
operation specified as expression's type. AND and OR became
ListExpressions. SQL generated is much nicer now:
...WHERE (t0.ARTIST_NAME = ?) OR (t0.ARTIST_NAME = ?) OR (t0.ARTIST_NAME =
?) OR (t0.ARTIST_NAME = ?)
And also I think I can create a simple algorithm for pruning subtrees for
the case described above ("prune everything up to the first ListExpression
parent in the tree).
Application code should work as before, unless somebody was explicitly
using ExpressionFactory.binaryExp() for AND/OR (I hope noone did, and used
"matchAll", "matchAny", "joinExp" instead). In this case an exception is
thrown prompting the user to upgrade to ListExpression.
I wonder if instead we should internally create a list expression, and just
print a big warning, but do not throw an exception?
Andrus
This archive was generated by hypermail 2.0.0 : Sun Jan 19 2003 - 16:52:52 EST