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 - 07:24:16 EDT