I'm a bit confused here. Let's try to make it clear.
First, the main goal of the feature is to provide extension point for
insert/update/delete queries of context commit process. 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.
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.
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.
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.
2009/6/3 Andrus Adamchik <andru..bjectstyle.org>
> Sorry for jumping the gun. Let me take it back for a moment. I was still
> trying to understand how do we present this feature to a user, and where it
> fits in the overall design. Now after this discussion, I am clear on the
> intention (I think), and more comfortable with the suggested concept and
> implementation.
>
> So intercepting things at the DataNode level is ok. I am +1 on that.
>
> One more question (you've probably thought it through already). The
> existing extension point for changing low level query behavior is
> DbAdapter.getAction(Query query, DataNode node). Should we build on that
> instead of adding another strategy to the DataNode? This seems particularly
> promising, since there is also a very common batch delete/update query -
> EJBQLQuery, that we'd need to handle. SQLAction overriding can apply to any
> kind of query.
>
> Thoughts?
> Andrus
>
>
>
> On Jun 3, 2009, at 1:36 PM, Andrus Adamchik wrote:
>
>> On Jun 3, 2009, at 12:01 PM, Andrey Razumovsky wrote:
>>
>> I've never used that myself, but e.g. DeleteBatchQuery can be fired
>>> separately using context.performAction(..). It is public in .query
>>> package
>>> after all. I don't want to have different behaviors for that
>>>
>>
>> I disagree. I think we do want delete query to behave like delete query,
>> and use the soft delete strategy for the objects managed by the context.
>>
>> Andrus
>>
>
>
This archive was generated by hypermail 2.0.0 : Wed Jun 03 2009 - 08:00:54 EDT