Hi,
I would really like to see many things that you suggested in Cayenne
(and don't really object to the reset :-)). Per your discussion with
Mike, in any possible implementation, the main issue to address is
cross-db compatibility. This can be done in Cayenne, since Query +
Expression are abstractions translated to SQL using
org.objectstyle.cayenne.access.QueryTranslator. Subclass of
QueryTranslator can be returned by DbAdapter, so e.g. EXISTS can be
substituted by WHERE count(1) > 0. Default implementation should
normally use the least common denominator.
On Monday, September 29, 2003, at 05:41 AM, Giulio Cesare Solaroli
wrote:
> In EOF we have written a few qualifiers (in Cayenne they are called
> expressions, if I get it right) like:
> - empty relationship;
> - not empty relationship;
> - no match for value;
I guess we need to define expression semantics first, and then see how
the SQL translation can be done. Something like Expression.IS_EMPTY,
Expression.IS_NOT_EMPTY?
> - match all values;
IN Expression already takes care of that.
> Plus, we have extended the editing context (in Cayenne it should be
> the DataContext) to implement a few method to:
> - return the number of records/objects matching a given
> qualifier/expression (select count(*));
> - return if a given expression matches any value (select dummy from
> dual where exists(...); similar to a select count(*) checking if the
> result is greater than zero, but much more efficient, as it returs as
> soon as it finds a match).
There is an undocumented feature (but actually even supported by the
modeler) called DerivedDbEntities. Those are DbEntities that allow
arbitrary expressions based on table columns described in a parent
DbEntity. This can be used for counts, GROUP BY, etc. It is
undocumented since I am still unsure that DerviedDbEntities is the way
to go... but this is something that should be fairly easy to use right
away at the DataContext level to retrieve things like counts.
SelectQuery has support for derived DbEntities (setParentObjEntityName,
setParentQualifier)...
I guess such special derived entities can be created on the fly
somewhere at the DataDomain level on demand (so that different
DataContexts can reuse them when needed). Now it the question of
defining API for all these pieces...and then we will gladly apply the
patches :-)
Andrus
This archive was generated by hypermail 2.0.0 : Mon Sep 29 2003 - 12:52:56 EDT