[
https://issues.jboss.org/browse/TEIID-4810?page=com.atlassian.jira.plugin...
]
Steven Hawkins reassigned TEIID-4810:
-------------------------------------
Assignee: (was: Steven Hawkins)
See TEIID-1598 for the server side logic, which is also covered in the docs -
https://teiid.gitbooks.io/documents/content/dev/Caching_API.html
In general there's just one method that the translator must implement to interact with
the result caching.
This issue is covering elevating that something that is built-in / configurable, and
exposed in the UI. I would recommend pursuing this as a low priority as the higher level
caching options generally offer more reuse and greater time savings.
Translator Caching
------------------
Key: TEIID-4810
URL:
https://issues.jboss.org/browse/TEIID-4810
Project: Teiid
Issue Type: Enhancement
Components: Misc. Connectors, Query Engine
Affects Versions: 9.3
Reporter: Van Halbert
we also have a whole different level of caching for custom translators
we could expand on that
we could cache on any source query
that’s not something we’ve talked about putting any higher level UI around
this would be a development and documentation effort
this is different than the whole model materialisation
the difference is that this is at a source query level
vs when you are using cache hints and extension metadata
we don’t have anything for the design-time user
that’s another feature set around caching that we could put some exposure on it
otherwise it’s not really exposed
the idea there is that if you want to do some higher level caching
you can build that into your models or your user query
we could turn it on and off without having to use a custom translator
MMX had a feature like that but it was convoluted because it was mixed up with the user
level query caching and they had to be enabled together
Attachments
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)