Re: [dtp-dev] reExecuteScript extension point

[Da-fan.Yang@xxxxxxxxxx]

Hi,Raghu,
Let me answer you these  one by one:
1. To re-execute a SP or UDF (User-defined function)
we may need more information other than the statement itself.
In fact, there is a data member named "_data"
in the OperationCommand class with which the consumer can store anything
-- it's opaque
and serializable, in this case, one can encapsulate
the necessary information and put it here for re-execution purpose.

2. Currently, it's up to the consumer to define the
behaviour of re-execution --- either execute the script directly or pop
up a dialog 
to allow the user to configure some parameters (Launch
config.). It would be nice of it to pop up the dialog to allow configuring
some parameters, 
so in the future we may consider add some utility
class to support such feature. Anyway, if vendors need to support such
behaviour now, more
work need to be done, it's doable.

3. The database_id and consumer_name is used to uniquely
identify a consumer. For example, Derby_10.1 in DTP may have two consumers
of SQL 
Results View -- SQL Editor and Routine Editor, which
may have different re-execution logic and two extensions need to be defined
to support 
re-execution, thus the ReExecutionRegistryReader will
find the appropriate extension by the database_id and consumer_name.

The exemplary implementation of re-execution would
be available in the near future.
All your questions and suggestions are really good
and helpful for us.
Thanks.

--------------------------------------------
DTP-Dev,
Any plans of giving a Derby reference implementation of 
org.eclipse.datatools.sqltools.result.reExecuteScript extension point ?

I am facing few issues here

1. I can re-execute ad-hoc sql queries (using the OperationCommand 
instance supplied to the IReExecutionRunnable) coming from either sql 
scrapbook editor or DTP Launch Configuration for Ad-hoc sql.
But for Stored Procedures re-execution OperationCommand doesn't look to
be sufficient info.
I suppose SP re-execution would need Launch Configuration or 
ProcIdentifier. A Launch Shortcut could have come handy.
There seems to be no association between the sqltools results framework
& the debug framework.
Is this a design limitation of org.eclipse.datatools.sqltools.result 
plugin ? Are there workarounds ?

2. From an end-user point of view, I think the execution history is not
intuitive. More than one place could be perceived as "history"
by a new user
a) Results view
b) whats persisted in the LaunchConfiguration Dialog (Run--> Run...
/ 
Debug...)
c) & the tool bar Run / Debug dropdowns is also a 'History'.
Should their History items not be in synch ? Since the DTP Launch 
Configs make use of Results View to display the results, re-execution 
from Results View should allow the user to view / modify the Launch 
Configuration.

3. The reExecuteScript extension point, expects a 'consumer_name' 
element. To an extender it's not obvious from extension pt. doc. who a
consumer is and what it wishes to consume.
Internally the ReExecutionRegistryReader would form IReExecutionRunnable
from the extension point only if the  
IResultInstance.OperationCommand.getConsumerName().equals(consumer_name).
The sql scrapbook editor hard codes the OperationCommand's consumer name
to 'SQL Editor'.
The Routine Editor &  SPLaunchConfigurationDelegate creates a
CallableSQLResultRunnable which hard codes it to 'Routine Editor'.
So these seem to be the only 2 possible literals for consumer_name.
Whats the intention here ?

I think re-execution from history is an important feature, more so 
because 're-execution' from editors & LCD creates a new row in history,
which IMHO is annoying.

Thoughts ?

Regards,
Raghu
_______________________________________________
dtp-dev mailing list
dtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dtp-dev


Best Regards & Wishes

Idull

Sybase China.
S/W Eng - Dev
Tel:0086-021-68799918-3102