[ https://issues.jboss.org/browse/TEIID-1598?page=com.atlassian.jira.plugin... ] Mark Addleman commented on TEIID-1598: -------------------------------------- Thinking about this issue and the streaming events: I can easily imagine streaming queries that join with non-streamable result sets. For example, suppose I want a stream of temperature readings by city but I have a set of weather stations that report temperature by station ID and, separately, I have a mapping table of station ID to city. It is possible that the data source supplying the mapping table is slow, so I would want to cache those results for the life of the query stream (something like read consistency). I suppose one solution would be to provide a materialized view of the mapping table. Alternatively, the query (or translator) could indicate that the result set is cachable for the life of query and Teiid could automaticaly set up sort of a private materialized view. Again, I consider this capability low priority. -- 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

[ https://issues.jboss.org/browse/TEIID-1598?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-1598: --------------------------------------- Just to circle back on an the 2/Nov comment, that will be handled as part of TEIID-2077. I think that the default behavior for continuous queries should be to cache everything that is not from a reusable execution. -- 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

[ https://issues.jboss.org/browse/TEIID-1598?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-1598: --------------------------------------- Sorry I wasn't clear. You have a comment on this issue above: "I can easily imagine streaming queries that join with non-streamable result sets. For example, suppose I want a stream of temperature readings by city but I have a set of weather stations that report temperature by station ID and, separately, I have a mapping table of station ID to city." I'm saying that will be handled as part of TEIID-2077 or can just as easily be left off as default behavior. As for the cache directive I'm mentioning here, it will be independent of continuous queries. It will look something like http://anonsvn.jboss.org/repos/teiid/trunk/api/src/main/java/org/teiid/tr... The basic functioning will be to add a method on the translator to ask for a CacheDirective for a given query prior to execution. Commands that may be in cache will then be looked up or will have their results properly buffered for reuse. The ExecutionContext will also be given the CacheDirective so that caching parameters can be adjusted by the Execution for when the results have been fully read and the cache entry created. -- 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

[ https://issues.jboss.org/browse/TEIID-1598?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-1598. ----------------------------------- Resolution: Done Added docs under the Developer's Guide and referenced from the Caching Guide. The 8.1 implementation does not provide any built-in caching configuration for translators, but it would be straight-forward to create a custom delegating translator that implements a caching policy. Follow-on issues are: - provide a built-in caching policy delegating translator, which could even use extension metadata to determine what commands are cached. - allow the translator to know the cardinality estimate for the source command - make use of the readAll option for regular result set cache entries, which currently don't get populated unless the entire result is constructed. -- 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

[ https://issues.jboss.org/browse/TEIID-1598?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-1598: --------------------------------------- Corrected the datatiertuplesource logic so that blocked exceptions would not prevent cache entry formation. This fix will be in CR1. -- 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