This discussion is very timely for me - I am in dire need of what I think
Giulio described as testing for "(not) empty relationships". In my case I
have some one-to-one relationships I want to filter on (filter based on the
existence of the relationship). The SQL to accomplish what I need is just a
simple join.
If I understand one of Andrus's earlier posts, extending QualifierTranslator
(and the db adapter that returns the instance of QualifierTranslator) would
be a way I can extend Cayenne to implement the behavior I'm looking for -
correct?
Like I said, I need something like this functionality now and am willing to
go the extension route and contribute back my findings.
That said, here are some musings -
There is an EXISTS expression type - if this were used as the type in an
unary expression with a SelectQuery as the operand - should this translate
to SELECT ... FROM T1 ... WHERE ... EXISTS (SELECT ... FROM T2 ... WHERE
....)?
If the EXISTS expression type was used in conjunction with an object path
that is a relationship in a unary expression, should it translate into:
SELECT ... FROM T1, T2 ... WHERE .... AND T1.PK = T2.PK
For a to-one relationship? And:
SELECT ... FROM T1 .... WHERE .... EXISTS (SELECT ... FROM T2 ... WHERE
T2.PK = T1.FK)
For a to-many relationship?
If I'm way off base and should leave the heavy lifting to the big boys - let
me know... ;-)
Scott
-----Original Message-----
From: Andrus Adamchik [mailto:andru..bjectstyle.org]
Sent: Wednesday, October 01, 2003 10:05 AM
To: cayenne-deve..bjectstyle.org
Subject: Re: I am missing Expression architecture
Hi Giulio Cesare,
I am writing an extended answer to your earlier e-mail that included
the discussion of Expressions. I'll send it out later today (still
trying to figure out a few things myself). Here is a snip from that
e-mail about the expressions...The design is indeed different from that
of EOF:
"Expression class simply defines semantics of the expression, and
doesn't contain any processing logic. ExpressionFactory hides all the
wiring and allows to create expressions using simple method names
following the "common logic". All the new methods can be defined under
ExpressionFactory. So I guess subclassing an expression won't buy us
much."
All processing logic is external to Expressions. Such design allowed to
avoid the explosion of subclasses, and also separate expressions from
such things like SQL generation, etc. ..Though I guess this makes it
harder to extend the algorithms used in conjunction with expressions.
> Where is the logic to use the expression to filter objects in memory?
Expression.eval() that delegates evaluation to EvalExpression class.
This feature is still not complete for all expression kinds.
> Where is the logic to create the SQL statement from an expression
> object? (Andrus has suggested me to look into QueryTranslator and
> QualifierTranslator)
Yes, this is the place. But as far as adding EXISTS support, etc., I
was still figuring out the best way.
More info coming...
Andrus
This archive was generated by hypermail 2.0.0 : Wed Oct 01 2003 - 12:00:49 EDT