On Jun 3, 2009, at 3:00 PM, Andrey Razumovsky wrote:
> First, the main goal of the feature is to provide extension point for
> insert/update/delete queries of context commit process.
This is what I thought initially. But you mentioning intercepting
delete queries at the lower levels made me think your intent was to
make things more generic, and rewrite every single delete going
through the system irregardless of origin?
In any event, both approaches do make sense. The first one is ok short
term (3.0). The second one - long term, considering that we want any
batch delete queries, except maybe SQLTemplate and ProcedureQuery, to
change the state of objects in the context, which we are not doing
now, "performQuery" becomes sort of like "commitChanges". Right now we
need to pick one approach for 3.0, and follow it consistently.
> Currently *BatchQueries are responsible for those actions. But they
> can be used
> separately. Should we keep original batch queries (e.g. if they are
> invoked
> in context.performQuery()) work as they did, ignoring user-provided
> 'strategy'? Who knows. If so, we need to create different types of
> queries
> in DDFlushAction. Current implementation says "no". I can stand both
> ways.
Let's first decide which approach above we'll be using (1. intercept
on commit or 2. intercept of anything "delete").
> Second, where should user-provided code be attached? Certainly, not
> to a
> datamap, as we discussed before. And not to DbAdapter. DbAdapter was
> designed to handle differences between DBMS and we definitely want
> user-provided behaviour act on all DBMS. So that should be DD or DN
> (data-node). As an example, there is new SchemaUpdateStrategy which
> in some
> other way specifies how Cayenne should affect on DB. It is DN
> property.
Looking at this one more time, I agree. This is irrelevant for
approach #1, but for #2 I think we can achieve what we need with a
DataNode bound SQLActionVisitor, which allows to process all types of
queries in a generic fashion (see below my notes on EJBQL).
> Third, should we push this behavior to other actions, e.g. EJBQL? I
> don't
> think so. EJBQL is same as SQL(Template) but in terms of object
> language (as
> far as I know, it works through SQLTemplate). So it's more "raw" than
> context's actions.
That's the thing - EJBQL, for all its similarity to SQLTemplate, is
not "raw". We don't have lots of usable object API around it yet, but
it is as OO as SelectQuery or a BatchQuery. It can be unambiguously
"compiled" back into a tree of mapping objects. So if we go with
strategy 2, DeleteBatchQuery and deleting EJBQL are the same beasts.
> Fourth, how should we pass the strategy to the place where query
> actions are
> performed? This is tricky implementation problem. If we create
> separate
> queries for "batches with user behavior", it'll be simple. Currently
> it
> works, although code seems not very clear to me.
Let's first decide which approach above we'll be using, and then
discuss this.
Andrus
This archive was generated by hypermail 2.0.0 : Wed Jun 03 2009 - 08:42:32 EDT