>
>
>
> Let's first decide which approach above we'll be using (1. intercept on
> commit or 2. intercept of anything "delete").
>
I see. What implemented now is "1.5 - intercept of anything
DeleteBatchQuery". This might be okay if we plan #2 someday. Actually I want
this feature right now, and changing EJBQL nature might be tricky. So I
suggest we either end with #1 or commit current code, which is little part
of #2.
>
> 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).
>
The most common SQLActionVisitor is JdbcActionBuilder and it cannot contain
reference to DataNode by design, as said before. I should say that uploaded
"DN bounded OperationObserver" allows to pass DN to ALL queries.
"Processing" e.g. ebjql and batch in generic fashion currently seems
imposible to me :(. They can logically do the same, but implementation is
too different.
As I already said, both long-plan ways are OK for me, but I wish to be able
to intercept context commit action as fast as possible.
This archive was generated by hypermail 2.0.0 : Wed Jun 03 2009 - 09:13:20 EDT