[JBoss JIRA] (TEIID-3871) moving documentation from confluence to gitbook
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-3871?page=com.atlassian.jira.plugin... ]
Kylin Soong updated TEIID-3871:
-------------------------------
Comment: was deleted
(was: I think your example is on the right track.
>From confluence there are epub and docbook exports that should be good starting points for http://pandoc.org/ (the html and default xml exports I'm not so sure about). Can you see what gives you the best bulk conversion option and then we can start manually correcting from there?)
> moving documentation from confluence to gitbook
> -------------------------------------------------
>
> Key: TEIID-3871
> URL: https://issues.jboss.org/browse/TEIID-3871
> Project: Teiid
> Issue Type: Task
> Components: Documentation
> Affects Versions: 9.x
> Reporter: Kylin Soong
> Assignee: Kylin Soong
> Fix For: 9.x
>
>
> From Teiid DV 7 F2F Notes,
> " In the Teiid 9.x timeframe we should look toward moving everything to gitbook / markdown. We should start by migrating the documentation and solicit help with the website if possible."
> This issue will address this.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 12 months
[JBoss JIRA] (TEIID-3896) When error occurs in the materialization process, an ERROR should be logged instead of DEBUG
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3896?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-3896.
-----------------------------------
Fix Version/s: 8.13
8.12.4
Resolution: Done
Changed the level to warn instead. There may be some instances when we need error level instead if the exception is low level, but I didn't account for that yet.
> When error occurs in the materialization process, an ERROR should be logged instead of DEBUG
> --------------------------------------------------------------------------------------------
>
> Key: TEIID-3896
> URL: https://issues.jboss.org/browse/TEIID-3896
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine
> Affects Versions: 8.12.2
> Reporter: Van Halbert
> Assignee: Steven Hawkins
> Priority: Minor
> Fix For: 8.13, 8.12.4
>
>
> When trying to do materialization, there's an issue (DEBUG) appearing in the server.log:
> 09:58:51,272 DEBUG [org.teiid.PROCESSOR] (Worker5_QueryProcessorQueue302) org.teiid.jdbc.TeiidSQLException: TEIID30168 Couldn't execute the dynamic SQL command "EXECUTE IMMEDIATE ('SELECT count(*) as rowCount FROM ' || matViewTable) AS rowCount integer INTO #load_count" with the SQL statement "('SELECT count(*) as rowCount FROM ' || matViewTable)" due to: Group specified is ambiguous, resubmit the query by fully qualifying the group name: Stock
> I believe this be logged as an ERROR as it appears to be detrimental to what's being materialized.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years
[JBoss JIRA] (TEIID-3725) In the JDG translators, enable named cache swapping so that materialization can be supported
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-3725?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-3725:
------------------------------------
Example dynamic vdb section to define the materialization:
{code}
CREATE view stockPricesMatView
(
productId integer,
symbol string,
price bigdecimal,
companyName varchar(256)
) OPTIONS (MATERIALIZED 'TRUE', UPDATABLE 'TRUE',
MATERIALIZED_TABLE 'StockMatCache.Stock',
"teiid_rel:MATVIEW_TTL" 60000,
"teiid_rel:MATVIEW_BEFORE_LOAD_SCRIPT" 'execute StockMatCache.native(''truncate cache'');',
"teiid_rel:MATVIEW_LOAD_SCRIPT" 'insert into StockMatCache.Stock (productId, symbol, price, companyName) SELECT A.ID, S.symbol, S.price, A.COMPANY_NAME FROM Stocks.StockPrices AS S, Accounts.PRODUCT AS A WHERE S.symbol = A.SYMBOL',
"teiid_rel:MATVIEW_AFTER_LOAD_SCRIPT" 'execute StockMatCache.native(''swap cache names'');',
"teiid_rel:MATVIEW_SHARE_SCOPE" 'NONE',
"teiid_rel:ALLOW_MATVIEW_MANAGEMENT" 'true',
"teiid_rel:MATVIEW_STATUS_TABLE" 'Accounts.status',
"teiid_rel:MATVIEW_ONERROR_ACTION" 'THROW_EXCEPTION')
AS SELECT A.ID, S.symbol, S.price, A.COMPANY_NAME
FROM Stocks.StockPrices AS S, Accounts.PRODUCT AS A
WHERE S.symbol = A.SYMBOL;
{code}
> In the JDG translators, enable named cache swapping so that materialization can be supported
> --------------------------------------------------------------------------------------------
>
> Key: TEIID-3725
> URL: https://issues.jboss.org/browse/TEIID-3725
> Project: Teiid
> Issue Type: Feature Request
> Components: Misc. Connectors
> Affects Versions: 8.12
> Reporter: Van Halbert
> Assignee: Van Halbert
>
> The JDG translators, that in order to support materialization, will need to enable the named cache that's referenced by the connection, to be swapped. This is due to JDG doesn't currently support renaming a cache (i.e., like table rename in JDBC). And because of that, it limits how the cache can be refreshed (don't want to clear it before re-loading).
> Ideas are:
> 1. configure translator with the 2 cache names to use (a) initial cache to read from and (b) the staging cache to use
> perform materialize load
> call SYSADMIN.setProperty to trigger the swapping of the cache names
> 2 ???
> Note: because there's no persistence in Teiid so that any cache name changes will outlive a server restart, when a restart occurs, the translator will read from the cache identified as the initial cache to read from.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years
[JBoss JIRA] (TEIID-3725) In the JDG translators, enable named cache swapping so that materialization can be supported
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-3725?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-3725:
------------------------------------
Comment from Adrian regarding improving usability of materialization:
So by "DV will reverse engineer from a table into the pojo to be used"
you mean DV will generate the pojo source code based on the columns DV
discovers in the db table? In that case it could also annotate its
java-bean like properties with our protobuf annotations (see Infinispan
Query Guide JDG 6.5, section 7.3.7). The protobuf schema would be
internally generated by JDG by inspecting those annotations, it will
also generate the entity marshallers so it would save DV a lot of work.
The process is described in [1].
Adrian
[1]
https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_Data_Grid/6.5...
Status:
The ability to perform materialization when JDG is in library mode has been done and tested. The jdg-local-cache quick start needs cleanup, but is essentially done.
The next step is to make the changes to the connector-infinispan-dsl resource adapter so that it handles the cache aliasing as the connector-infinispan.6 resource adapter (library mode). Also, based on Adrian's suggestion, I'll go ahead and add the logic to check the class for protobuf annotations so that the cache can be configured accordingly.
> In the JDG translators, enable named cache swapping so that materialization can be supported
> --------------------------------------------------------------------------------------------
>
> Key: TEIID-3725
> URL: https://issues.jboss.org/browse/TEIID-3725
> Project: Teiid
> Issue Type: Feature Request
> Components: Misc. Connectors
> Affects Versions: 8.12
> Reporter: Van Halbert
> Assignee: Van Halbert
>
> The JDG translators, that in order to support materialization, will need to enable the named cache that's referenced by the connection, to be swapped. This is due to JDG doesn't currently support renaming a cache (i.e., like table rename in JDBC). And because of that, it limits how the cache can be refreshed (don't want to clear it before re-loading).
> Ideas are:
> 1. configure translator with the 2 cache names to use (a) initial cache to read from and (b) the staging cache to use
> perform materialize load
> call SYSADMIN.setProperty to trigger the swapping of the cache names
> 2 ???
> Note: because there's no persistence in Teiid so that any cache name changes will outlive a server restart, when a restart occurs, the translator will read from the cache identified as the initial cache to read from.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years
[JBoss JIRA] (TEIID-3900) OData - malformed URL causes NPE
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3900?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3900:
---------------------------------------
Added another commit to refine the exceptional behavior. The general contract is to return null or a valid producer from the getContext call and so our exceptions were causing 500 errors rather than 404s as expected.
> OData - malformed URL causes NPE
> --------------------------------
>
> Key: TEIID-3900
> URL: https://issues.jboss.org/browse/TEIID-3900
> Project: Teiid
> Issue Type: Bug
> Components: OData
> Affects Versions: 8.12.3
> Reporter: Juraj Duráni
> Assignee: Juraj Duráni
> Fix For: 8.13, 8.12.4
>
>
> Malformed URL \[1\] causes NPE in Teiid \[2\].
> \[1\] http://localhost:8080/odata/test$metadata (missing '/' after VDB name)
> \[2\]
> {code:text}
> [org.teiid.ODATA] (http-/127.0.0.1:8080-1) TEIID16013 Error occurred producing OData result.: java.lang.NullPointerException
> at org.teiid.odbc.ODBCServerRemoteImpl.setConnectionProperties(ODBCServerRemoteImpl.java:304) [teiid-runtime-8.12.3.redhat-1.jar:8.12.3.redhat-1]
> at org.teiid.odata.LocalClient.getConnection(LocalClient.java:167) [classes:]
> at org.teiid.odata.LocalClient.getVDB(LocalClient.java:139) [classes:]
> at org.teiid.odata.LocalClient.getMetadata(LocalClient.java:484) [classes:]
> at org.teiid.odata.TeiidProducer.getMetadata(TeiidProducer.java:83) [classes:]
> at org.odata4j.producer.resources.ServiceDocumentResource.getServiceDocument(ServiceDocumentResource.java:35) [odata-core-0.8.10.jar:0.8.10]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_40]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_40]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_40]
> at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_40]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:168) [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269) [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227) [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:216) [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:561) [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:543) [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:128) [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
> at org.teiid.odata.ODataServletContainerDispatcher.service(ODataServletContainerDispatcher.java:118) [classes:]
> at org.teiid.odata.ODataServlet.service(ODataServlet.java:65) [classes:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:512) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.5.4.Final-redhat-4.jar:7.5.4.Final-redhat-4]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_40]
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years
[JBoss JIRA] (TEIID-3725) In the JDG translators, enable named cache swapping so that materialization can be supported
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-3725?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-3725:
------------------------------------
When the resource-adapter is configured for materialization, the following assumptions are made:
- any insert/update/delete will be performed against the staging cache.
- any read will be performed against the primary cache.
- as part of the materialization process, the updates will be performed as specified in the MATVIEW_LOAD_SCRIPT option.
example:
{code}
"teiid_rel:MATVIEW_LOAD_SCRIPT" 'insert into StockMatCache.Stock (productId, symbol, price, companyName) SELECT A.ID, S.symbol, S.price, A.COMPANY_NAME FROM Stocks.StockPrices AS S, Accounts.PRODUCT AS A WHERE S.symbol = A.SYMBOL',
{code}
> In the JDG translators, enable named cache swapping so that materialization can be supported
> --------------------------------------------------------------------------------------------
>
> Key: TEIID-3725
> URL: https://issues.jboss.org/browse/TEIID-3725
> Project: Teiid
> Issue Type: Feature Request
> Components: Misc. Connectors
> Affects Versions: 8.12
> Reporter: Van Halbert
> Assignee: Van Halbert
>
> The JDG translators, that in order to support materialization, will need to enable the named cache that's referenced by the connection, to be swapped. This is due to JDG doesn't currently support renaming a cache (i.e., like table rename in JDBC). And because of that, it limits how the cache can be refreshed (don't want to clear it before re-loading).
> Ideas are:
> 1. configure translator with the 2 cache names to use (a) initial cache to read from and (b) the staging cache to use
> perform materialize load
> call SYSADMIN.setProperty to trigger the swapping of the cache names
> 2 ???
> Note: because there's no persistence in Teiid so that any cache name changes will outlive a server restart, when a restart occurs, the translator will read from the cache identified as the initial cache to read from.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years