The more I think about it, the more I am convinced that we need a
separate delegate interface for DataContext. DataContextDelegate is a
good start :-)...
Current OperationObserver already combines too many things from
different areas of Cayenne. Besides the main flow of query execution
relies on particular implementations of Observer, so it is not good for
custom delegation. Another alternative - using DataContext events -
(that we discussed with Dirk and Holger) is not satisfactory to me
either (though some would probably disagree with me on that :
http://objectstyle.org/cayenne/lists/cayenne-devel/2003/09/0005.html ).
So I vote for the new interface.. something like this:
org.objectstyle.cayenne.access.DataContextDelegate
// note the name change from the original "willPerformQuery" - we do
not want to call this
// for any query, just for selects...
public GenericSelectQuery willPerformSelect(DataContext context,
GenericSelectQuery query)
// other methods... we may add them as we go
// e.g. shouldValidateObjects(..), shouldCommit(..) etc.
Should be very easy to plug this in to the DataContext.
Andrus
On Wednesday, September 24, 2003, at 12:26 PM, Mike Kienenberger wrote:
> Andrus Adamchik <andru..bjectstyle.org> wrote:
>> For now as an easy fix I suggest another API change. Add a method like
>> "willPerformQuery" to an OperationObserver interface, and then allow
>> setting custom OperationObserver on DataContext. This will expand the
>> delegation capabilities of Cayenne in general, and would allow to
>> customize code for your particular case. Internally we can chain
>> custom
>> observer with default ones provided by Cayenne so that even a noop
>> custom class wouldn't break DataContext behavior.
>
> Are you suggesting that I modify OperationObserver or that I create
> another
> interface like OperationObserver? Along those lines, are you
> suggesting
> that the custom OperationObserver replace all internal
> OperationObservers or
> that it mirror/duplicate whatever methods are called for the current
> OperationObserver classes?
>
> My interpretation is that I should modify OperationalObserver, and
> somehow
> use the Custom OperationalObserver in addition to what's already there.
>
> And what should the signature for "willPerformQuery" be?
>
> public void willPerformQuery(Query) -- Not sure how this allows me to
> modify
> it. Matches signatures of existing methods.
>
> public boolean willPerformQuery(Query) -- Would allow you to veto an
> operation, but not modify it. Matches name of method.
>
> public Query willPerformQuery(Query) -- Would allow returning a new
> query or
> null to veto it. Provides useful functionality :)
>
>
This archive was generated by hypermail 2.0.0 : Wed Sep 24 2003 - 21:02:45 EDT