[
https://issues.jboss.org/browse/TEIID-1801?page=com.atlassian.jira.plugin...
]
Steven Hawkins commented on TEIID-1801:
---------------------------------------
With a reset/re-run approach, something like an order by would be particular to the window
and so does not need to be handled as an error.
Now that we have exposed an asynch method in JDBC, that would probably be a good spot to
initiate a re-runable plan,
e.g. void submitExecute(String sql, StatementCallback callback, boolean rerun) throws
SQLException
This could even be the place to indicate the time window. We would just have to add
another piece of information to the ExectionContext. Another possible approach to a
configurable time window would be to use the source hint
https://issues.jboss.org/browse/TEIID-1726 feature "SELECT /*+ sh:window(10) */ ...
".
I think the caching concerns can be handled more generally, such as translator result set
caching, with a session temp table, or possibly by having the with clause not be reset in
streaming mode - but that may need to be hint driven.
Async Event Processing: Reset and Re-run plan
----------------------------------------------
Key: TEIID-1801
URL:
https://issues.jboss.org/browse/TEIID-1801
Project: Teiid
Issue Type: Feature Request
Reporter: Mark Addleman
Assignee: Steven Hawkins
In order to processing a stream of events aggregated within a specified time window, the
engine should provide some way of specifying the time period (analogous to a window),
reset and re-rerun the plan for every time period. There should also be an engine to
translator callback indicating that the plan has been reset as opposed to closed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira