[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:
------------------------------------
Also, the user can configure a RemoteCacheManager and bind it to JNDI. For which each resource adapter can share. That is also an option.
> 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)
8 years, 12 months
[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:
------------------------------------
Each connection shares the same Cache Container via the reference back to the resource-adapter config factory. The connectionImpl is very light weight.
> 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)
8 years, 12 months
[JBoss JIRA] (TEIID-3725) In the JDG translators, enable named cache swapping so that materialization can be supported
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3725?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3725:
---------------------------------------
It matters most how heavy weight each connection is. If they hold a significant amount of resources per connection / resource adapter, then it would definitely make sense to to move toward a single resource adapter - as we are likely to promote more general usage of JDG for materialization.
> 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)
8 years, 12 months
[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:
------------------------------------
I don't disagree that its not optimal. However, until the latest releases of JDG, are there options to do all the configuration from the client side (i.e., configure protobuf on the server from the client). Which would now enable the resource adapter to be more flexible. But that would be a major change in configuration/migration for what's already available. So I've resisted making sweeping changes that would cause compatibility issues. Unless we want to create a brand new resource-adapater/translator for users to transition to.
> 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)
8 years, 12 months
[JBoss JIRA] (TEIID-3878) java.lang.Integer cannot be cast to java.math.BigDecimal
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3878?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3878:
---------------------------------------
Still no luck reproducing this. I'll need a more complete reproduction scenario to make progress.
> java.lang.Integer cannot be cast to java.math.BigDecimal
> --------------------------------------------------------
>
> Key: TEIID-3878
> URL: https://issues.jboss.org/browse/TEIID-3878
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.11.3
> Reporter: Mark Tawk
> Assignee: Steven Hawkins
> Priority: Critical
> Attachments: TEIID-3878.sql
>
>
> I'm using Teiid 8.11.3 with oracle translator.
> I have an aggregated query using teiid materialized views with the following simplified criteria:
> (CASE WHEN ( "table1"."field1" = 1 ) THEN "table2"."yearfield" ELSE null END IN (2014) )
> The above criteria is reproducing a ClassCastException Integer cannot be cast to BigDecimal
> if I change the criteria to the following, it passes without a problem:
> ("table2"."yearfield" IN (2014) )
> Here is the error stack:
> java.lang.ClassCastException: java.lang.Integer cannot be cast to java.math.BigDecimal
> at java.math.BigDecimal.compareTo(BigDecimal.java:219)
> at org.teiid.query.sql.symbol.Constant$2.compare(Constant.java:99)
> at org.teiid.query.eval.Evaluator.compare(Evaluator.java:581)
> at org.teiid.query.eval.Evaluator.evaluate(Evaluator.java:322)
> at org.teiid.query.eval.Evaluator.internalEvaluateTVL(Evaluator.java:236)
> at org.teiid.query.eval.Evaluator.evaluateTVL(Evaluator.java:225)
> at org.teiid.query.eval.Evaluator.evaluate(Evaluator.java:219)
> at org.teiid.query.processor.relational.JoinNode.matchesCriteria(JoinNode.java:353)
> at org.teiid.query.processor.relational.EnhancedSortMergeJoinStrategy.process(EnhancedSortMergeJoinStrategy.java:460)
> at org.teiid.query.processor.relational.JoinNode.nextBatchDirect(JoinNode.java:227)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:278)
> at org.teiid.query.processor.BatchCollector$BatchProducerTupleSource.nextTuple(BatchCollector.java:94)
> at org.teiid.query.processor.relational.GroupingNode.groupSortPhase(GroupingNode.java:490)
> at org.teiid.query.processor.relational.GroupingNode.nextBatchDirect(GroupingNode.java:366)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:278)
> at org.teiid.query.processor.relational.ProjectNode.nextBatchDirect(ProjectNode.java:148)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:278)
> at org.teiid.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:145)
> at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:151)
> at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:114)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:164)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:146)
> at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:457)
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:339)
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51)
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:267)
> at org.teiid.dqp.internal.process.DQPCore.executeRequest(DQPCore.java:306)
> at org.teiid.dqp.internal.process.DQPCore.executeRequest(DQPCore.java:238)
> at sun.reflect.GeneratedMethodAccessor260.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.teiid.transport.LocalServerConnection$1$1.call(LocalServerConnection.java:175)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:276)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:260)
> at org.teiid.transport.LocalServerConnection$1.invoke(LocalServerConnection.java:173)
> at com.sun.proxy.$Proxy31.executeRequest(Unknown Source)
> at org.teiid.jdbc.StatementImpl.execute(StatementImpl.java:667)
> at org.teiid.jdbc.StatementImpl.executeSql(StatementImpl.java:533)
> at org.teiid.jdbc.StatementImpl.execute(StatementImpl.java:1068)
> at org.teiid.jdbc.StatementImpl.execute(StatementImpl.java:320)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 12 months
[JBoss JIRA] (TEIID-3878) java.lang.Integer cannot be cast to java.math.BigDecimal
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3878?page=com.atlassian.jira.plugin... ]
Work on TEIID-3878 stopped by Steven Hawkins.
---------------------------------------------
> java.lang.Integer cannot be cast to java.math.BigDecimal
> --------------------------------------------------------
>
> Key: TEIID-3878
> URL: https://issues.jboss.org/browse/TEIID-3878
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.11.3
> Reporter: Mark Tawk
> Assignee: Steven Hawkins
> Priority: Critical
> Attachments: TEIID-3878.sql
>
>
> I'm using Teiid 8.11.3 with oracle translator.
> I have an aggregated query using teiid materialized views with the following simplified criteria:
> (CASE WHEN ( "table1"."field1" = 1 ) THEN "table2"."yearfield" ELSE null END IN (2014) )
> The above criteria is reproducing a ClassCastException Integer cannot be cast to BigDecimal
> if I change the criteria to the following, it passes without a problem:
> ("table2"."yearfield" IN (2014) )
> Here is the error stack:
> java.lang.ClassCastException: java.lang.Integer cannot be cast to java.math.BigDecimal
> at java.math.BigDecimal.compareTo(BigDecimal.java:219)
> at org.teiid.query.sql.symbol.Constant$2.compare(Constant.java:99)
> at org.teiid.query.eval.Evaluator.compare(Evaluator.java:581)
> at org.teiid.query.eval.Evaluator.evaluate(Evaluator.java:322)
> at org.teiid.query.eval.Evaluator.internalEvaluateTVL(Evaluator.java:236)
> at org.teiid.query.eval.Evaluator.evaluateTVL(Evaluator.java:225)
> at org.teiid.query.eval.Evaluator.evaluate(Evaluator.java:219)
> at org.teiid.query.processor.relational.JoinNode.matchesCriteria(JoinNode.java:353)
> at org.teiid.query.processor.relational.EnhancedSortMergeJoinStrategy.process(EnhancedSortMergeJoinStrategy.java:460)
> at org.teiid.query.processor.relational.JoinNode.nextBatchDirect(JoinNode.java:227)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:278)
> at org.teiid.query.processor.BatchCollector$BatchProducerTupleSource.nextTuple(BatchCollector.java:94)
> at org.teiid.query.processor.relational.GroupingNode.groupSortPhase(GroupingNode.java:490)
> at org.teiid.query.processor.relational.GroupingNode.nextBatchDirect(GroupingNode.java:366)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:278)
> at org.teiid.query.processor.relational.ProjectNode.nextBatchDirect(ProjectNode.java:148)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:278)
> at org.teiid.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:145)
> at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:151)
> at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:114)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:164)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:146)
> at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:457)
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:339)
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51)
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:267)
> at org.teiid.dqp.internal.process.DQPCore.executeRequest(DQPCore.java:306)
> at org.teiid.dqp.internal.process.DQPCore.executeRequest(DQPCore.java:238)
> at sun.reflect.GeneratedMethodAccessor260.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.teiid.transport.LocalServerConnection$1$1.call(LocalServerConnection.java:175)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:276)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:260)
> at org.teiid.transport.LocalServerConnection$1.invoke(LocalServerConnection.java:173)
> at com.sun.proxy.$Proxy31.executeRequest(Unknown Source)
> at org.teiid.jdbc.StatementImpl.execute(StatementImpl.java:667)
> at org.teiid.jdbc.StatementImpl.executeSql(StatementImpl.java:533)
> at org.teiid.jdbc.StatementImpl.execute(StatementImpl.java:1068)
> at org.teiid.jdbc.StatementImpl.execute(StatementImpl.java:320)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 12 months
[JBoss JIRA] (TEIID-3725) In the JDG translators, enable named cache swapping so that materialization can be supported
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3725?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3725:
---------------------------------------
The concern would be around how many resources would be consumed by each connection pool. If you wanted to have 10 things materialized you would have 10 pools each with x connections.
> 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)
8 years, 12 months
[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 edited comment on TEIID-3725 at 1/14/16 10:55 AM:
--------------------------------------------------------------
Currently yes, because the configuration indicates what class, cache name, marshaller, protobuf file, etc. per cache. It would get complicated to configure multiple caches per resource adapter. Unless those configuration options were moved to the translator, and just let the resource adapter deal with the cache container.
(removed the last sentence, its not necessarily true)
was (Author: van.halbert):
Currently yes, because the configuration indicates what class, cache name, marshaller, protobuf file, etc. per cache. It would get complicated to configure multiple caches per resource adapter. Unless those configuration options were moved to the translator, and just let the resource adapter deal with the cache container. However, that would push more logic down into the translator to know how to deal specifically with the local cache versus remote cache, because they are different.
> 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)
8 years, 12 months
[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:
------------------------------------
Currently yes, because the configuration indicates what class, cache name, marshaller, protobuf file, etc. per cache. It would get complicated to configure multiple caches per resource adapter. Unless those configuration options were moved to the translator, and just let the resource adapter deal with the cache container. However, that would push more logic down into the translator to know how to deal specifically with the local cache versus remote cache, because they are different.
> 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)
8 years, 12 months
[JBoss JIRA] (TEIID-3725) In the JDG translators, enable named cache swapping so that materialization can be supported
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3725?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3725:
---------------------------------------
Just wanted to check what you mean by the resource adapter will know the name of what is being truncated/swapped. Can there only be a single materialization per resource adapter?
> 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)
8 years, 12 months