[
https://issues.jboss.org/browse/TEIID-2584?page=com.atlassian.jira.plugin...
]
Ramesh Reddy commented on TEIID-2584:
-------------------------------------
It seems like the events are asymetrical - one is basically for every
vdb startup and the other is for once the vdb is removed. Who then is responsible for the
removal of the materialization table / staging table? Or are you leaving that off to avoid
complications with sharing the mat view across redeployments.
Yes, since there was no real way to detect if the vdb is deployed first time vs restart it
is being executed every time, I could not think of a way to differentiate between them. By
providing hooks at the different events, I would like defer those cleaning activities to
user such that they can be used in sharing scenarios. At first, I had script automatically
deleting them, then with scoping I opted to this option. Can you think any way to limit to
one execution? I thought may be metadata caching, or may be I can ask AS for deployment
artifact time to figure out it is new deploy vs old.
How will permissioning work with stuff that is executed by the
materialization manager? That is what expectations need to be satisfied so that DDL/native
queries can be executed - but not necessarily requiring exposing that as general user
functionality.
I was thinking, we should extend the vdb.xml's source element to take a optional
"admin-connection-jndi-name" attribute that defines a separate connection, where
through some mechanism (hint or execution property) we can instruct ConnectionManager to
use that connection instead of regular "connection-jndi-name".
It seems like we may also have to tweak the before/after load scripts
as not all dbs support executing multiple statements together.
Yes, I will fix it.
Same may be true, when "load" script is present. User can optionally specify
"load" script too.
Add management features to materialization
------------------------------------------
Key: TEIID-2584
URL:
https://issues.jboss.org/browse/TEIID-2584
Project: Teiid
Issue Type: Feature Request
Reporter: Ramesh Reddy
Assignee: Ramesh Reddy
Labels: Beta3
Fix For: 8.5
Currently Teiid supports internal and external materialization features. The internal is
managed completely by the Teiid query engine along with the infinispan cache.
External materialization is completely unmanaged and left out to the user to manage it
externally. This goals for this feature are unify the materialization logic for internal
and external, such that both are managed similarly irrespective of the type of
materialization chosen.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira