On Monday, Sep 29, 2003, at 18:52 Europe/Rome, Andrus Adamchik wrote:
> 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?
I agree that a semantics is to be defined, but I don't think that
Expression.IS_EMPTY could match always with the semantic of an
EmptyRelationshipExpression.
>> - match all values;
>
> IN Expression already takes care of that.
Here too, the IN Expression behaves like the "match all values"
expression when used on to-one relationships. As soos as you have one
or more to-many relationship to follow, the semantics of the two
expressions will diverge.
I'll take some time in the near future to post a detail explanation on
what we have found (problems and solutions) while writing our
extensions to EOF in order to show that in order to preserve the
matching between "common logic" and "relational logic" a more complete
and sophisticated solution is needed.
>> 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 :-)
I am very interested in writing this extensions and providing back the
patches; I was asking some help on finding the right places to look at
This archive was generated by hypermail 2.0.0 : Tue Sep 30 2003 - 04:12:34 EDT