[JBoss JIRA] (TEIID-5063) Issues with bigdecimal values and odata
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5063?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-5063.
-----------------------------------
Resolution: Done
Updated the visitor logic, changed to just trim trailing 0's, and corrected the odata translator for emitting literals/parameters. Olingo even with a null precision needs a value for scale as it assumes 0 otherwise, which could be a bug on their part.
> Issues with bigdecimal values and odata
> ---------------------------------------
>
> Key: TEIID-5063
> URL: https://issues.jboss.org/browse/TEIID-5063
> Project: Teiid
> Issue Type: Bug
> Components: OData
> Affects Versions: 9.1, 8.12.x-6.4
> Reporter: Andrej Šmigala
> Assignee: Steven Hawkins
> Priority: Blocker
> Fix For: 10.0, 8.12.x-6.4, 9.3.4, 9.2.6
>
>
> Usage of bigdecimal literals in odata4 translator literals or procedure parameters results in an exception about the facet not being satisfied.
> We are also with TEIID-4269 we were allowing more than just trailing 0s to be trimmed from the numeric values. This results in situations where you could return an entity with a value, but could not look it up by that value (as it would no longer be equal). We should instead let the facet fail if we can't just trim zeros.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months
[JBoss JIRA] (TEIID-2542) Utilize Teiid internal resultset buffering as a materialization mechanism to Infinspan
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2542?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-2542:
----------------------------------
Fix Version/s: 10.x
(was: 10.0)
> Utilize Teiid internal resultset buffering as a materialization mechanism to Infinspan
> --------------------------------------------------------------------------------------
>
> Key: TEIID-2542
> URL: https://issues.jboss.org/browse/TEIID-2542
> Project: Teiid
> Issue Type: Feature Request
> Components: Misc. Connectors
> Reporter: Van Halbert
> Fix For: 10.x
>
>
> Add support for materialization to Infinispan by utilizing the Teiid internal buffering mechanism to Infinispan. Suggestion, turn that mechanism into a translator that can read/write to Infinispan.
> Pro's:
> - distributed data-grid fail-over and HA could be less costly than trying to do this with a database.
> - improved performance where each Infinispan instance could placed closer to its' users.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months
[JBoss JIRA] (TEIID-5060) Infinispan Hotrod Translator UPDATE on primary key column
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5060?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5060:
---------------------------------------
[~rareddy] the flag is in 8.12.x. It was changed to default to false in 9.0 since that impacts compatibility.
> Infinispan Hotrod Translator UPDATE on primary key column
> ---------------------------------------------------------
>
> Key: TEIID-5060
> URL: https://issues.jboss.org/browse/TEIID-5060
> Project: Teiid
> Issue Type: Bug
> Components: JDG Connector, Misc. Connectors
> Reporter: Jan Stastny
> Assignee: Ramesh Reddy
> Priority: Blocker
> Fix For: 10.0
>
>
> UPDATE query where the PRIMARY KEY of the table is being changed succeeds, returns update count of corresponding rows, but the changes don't get promoted to actual cache.
> Consider
> {code:sql|title=UPDATE query}
> UPDATE SmallA SET StringKey = 100 WHERE IntKey > 25
> {code}
> where StringKey is set as PRIMARY KEY and 6 rows fulfill the filter on IntKey>25.
> When this UPDATE is performed, returned number of rows update is 6, but the contents of the cache don't change.
> There are several applicable resolutions:
> # There should be error thrown by Teiid, that this is not allowed operation
> # There should be update count 0 returned
> # There should be change in JDG cache, effectively squashing the 6 rows into single one
> # There should be error thrown by Teiid, that there is duplicate PK value (this is not something Teiid usually enforces)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months
[JBoss JIRA] (TEIID-5062) Infinispan Hotrod Translator NPE for DELETE with WHERE clause on a view
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-5062?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-5062:
-------------------------------------
This seems to be related to TEIID-5060
> Infinispan Hotrod Translator NPE for DELETE with WHERE clause on a view
> -----------------------------------------------------------------------
>
> Key: TEIID-5062
> URL: https://issues.jboss.org/browse/TEIID-5062
> Project: Teiid
> Issue Type: Bug
> Components: JDG Connector, Misc. Connectors
> Affects Versions: 8.12.x-6.4
> Reporter: Jan Stastny
> Assignee: Ramesh Reddy
> Priority: Blocker
>
> A delete query against a view fails, when in WHERE clause there is a filter on non-directly mapped column. Please note, that the integer type is only example, this happens for any type (time/date/timestamp amongst other).
> {code:xml|title=vdb}
> <vdb name="teiidVdb" version="1">
> <model name="Source" type="PHYSICAL" visible="false">
> <source name="jdg7-source" translator-name="infinispan-hotrod" connection-jndi-name="java:/jdg71HotrodDS" />
> <metadata type="DDL"><![CDATA[
> CREATE FOREIGN TABLE SmallA (
> IntValue string,
> StringKey string PRIMARY KEY
> ) OPTIONS(UPDATABLE true, "teiid_ispn:cache" 'jdg71_crud_null');
> ]]>
> </metadata>
> <metadata type = "NATIVE"/>
> </model>
> <model name="CRUD" type="VIRTUAL">
> <metadata type="DDL"><![CDATA[
> CREATE VIEW SmallA(
> IntValue integer,
> StringKey string PRIMARY KEY
> ) OPTIONS (UPDATABLE true) AS
> SELECT
> CONVERT(source.IntValue,integer), source.StringKey FROM Source.SmallA as source;
> CREATE TRIGGER on SmallA INSTEAD OF INSERT AS FOR EACH ROW
> BEGIN ATOMIC
> INSERT INTO Source.SMallA(StringKey,IntValue) VALUES (NEW.StringKey, CONVERT(NEW.IntValue,string));
> END;
> ]]>
> </metadata>
> </model>
> </vdb>
> {code}
> And following query:
> {code:sql|title=DELETE query}
> DELETE FROM SmallA WHERE IntValue=13
> {code}
> I get an error:
> {code:title=error}
> 17:07:46,315 ERROR [org.teiid.CONNECTOR] (Worker1_QueryProcessorQueue15) Connector worker process failed for atomic-request=egwECKP/+/aS.7.2.8: java.lang.NullPointerException
> at org.teiid.translator.infinispan.hotrod.IckleConversionVisitor.visit(IckleConversionVisitor.java:274) [translator-infinispan-hotrod-8.12.11.6_4-redhat-6.jar:8.12.11.6_4-redhat-6]
> at org.teiid.language.DerivedColumn.acceptVisitor(DerivedColumn.java:47) [teiid-api-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.language.visitor.AbstractLanguageVisitor.visitNode(AbstractLanguageVisitor.java:51) [teiid-api-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.language.visitor.AbstractLanguageVisitor.visitNodes(AbstractLanguageVisitor.java:63) [teiid-api-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.translator.infinispan.hotrod.IckleConversionVisitor.visit(IckleConversionVisitor.java:248) [translator-infinispan-hotrod-8.12.11.6_4-redhat-6.jar:8.12.11.6_4-redhat-6]
> at org.teiid.language.Select.acceptVisitor(Select.java:110) [teiid-api-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.language.visitor.AbstractLanguageVisitor.visitNode(AbstractLanguageVisitor.java:51) [teiid-api-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.language.visitor.SQLStringVisitor.append(SQLStringVisitor.java:91) [teiid-api-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.translator.infinispan.hotrod.InfinispanQueryExecution.execute(InfinispanQueryExecution.java:77) [translator-infinispan-hotrod-8.12.11.6_4-redhat-6.jar:8.12.11.6_4-redhat-6]
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.execute(ConnectorWorkItem.java:363) [teiid-engine-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_121]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_121]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_121]
> at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_121]
> at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:211) [teiid-engine-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at com.sun.proxy.$Proxy79.execute(Unknown Source)
> at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:306) [teiid-engine-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.dqp.internal.process.DataTierTupleSource.nextTuple(DataTierTupleSource.java:142) [teiid-engine-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.query.processor.relational.AccessNode.nextBatchDirect(AccessNode.java:391) [teiid-engine-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:281) [teiid-engine-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.query.processor.relational.SelectNode.nextBatchDirect(SelectNode.java:104) [teiid-engine-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:281) [teiid-engine-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.query.processor.relational.ProjectNode.nextBatchDirect(ProjectNode.java:150) [teiid-engine-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:281) [teiid-engine-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:145) [teiid-engine-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:151) [teiid-engine-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:114) [teiid-engine-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.query.processor.BatchIterator.finalRow(BatchIterator.java:69) [teiid-engine-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.common.buffer.AbstractTupleSource.getCurrentTuple(AbstractTupleSource.java:70) [teiid-engine-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.query.processor.BatchIterator.getCurrentTuple(BatchIterator.java:84) [teiid-engine-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.common.buffer.AbstractTupleSource.hasNext(AbstractTupleSource.java:92) [teiid-engine-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.query.processor.proc.ProcedurePlan.executePlan(ProcedurePlan.java:616) [teiid-engine-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.query.processor.proc.LoopInstruction.testCondition(LoopInstruction.java:108) [teiid-engine-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.query.processor.proc.ProcedurePlan.processProcedure(ProcedurePlan.java:379) [teiid-engine-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.query.processor.proc.ProcedurePlan.nextBatchDirect(ProcedurePlan.java:298) [teiid-engine-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.query.processor.proc.ProcedurePlan.nextBatch(ProcedurePlan.java:270) [teiid-engine-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.query.processor.relational.PlanExecutionNode.nextBatchDirect(PlanExecutionNode.java:118) [teiid-engine-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:281) [teiid-engine-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:145) [teiid-engine-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:151) [teiid-engine-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:114) [teiid-engine-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:164) [teiid-engine-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:146) [teiid-engine-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:472) [teiid-engine-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:348) [teiid-engine-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51) [teiid-engine-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:274) [teiid-engine-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:280) [teiid-engine-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) [teiid-engine-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210) [teiid-engine-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_121]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_121]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_121]
> 17:07:46,317 WARN [org.teiid.PROCESSOR] (Worker1_QueryProcessorQueue15) TEIID30020 Processing exception for request egwECKP/+/aS.7 'TEIID30504 jdg7-source: null'. Originally TeiidProcessingException IckleConversionVisitor.java:274. Enable more detailed logging to see the entire stacktrace.
> {code}
> * This happens on both empty and non-empty cache.
> * For a column, which is directly mapped from a source column to view column, such problem doesn't exist.
> * Given the limited type support on JDG's side I consider this blocking issue, as there's no workaround for such operation.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months
[JBoss JIRA] (TEIID-5060) Infinispan Hotrod Translator UPDATE on primary key column
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-5060?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-5060:
-------------------------------------
@shawkins I guess this needs to be pulled into the 8.12.x branch?
> Infinispan Hotrod Translator UPDATE on primary key column
> ---------------------------------------------------------
>
> Key: TEIID-5060
> URL: https://issues.jboss.org/browse/TEIID-5060
> Project: Teiid
> Issue Type: Bug
> Components: JDG Connector, Misc. Connectors
> Reporter: Jan Stastny
> Assignee: Ramesh Reddy
> Priority: Blocker
> Fix For: 10.0
>
>
> UPDATE query where the PRIMARY KEY of the table is being changed succeeds, returns update count of corresponding rows, but the changes don't get promoted to actual cache.
> Consider
> {code:sql|title=UPDATE query}
> UPDATE SmallA SET StringKey = 100 WHERE IntKey > 25
> {code}
> where StringKey is set as PRIMARY KEY and 6 rows fulfill the filter on IntKey>25.
> When this UPDATE is performed, returned number of rows update is 6, but the contents of the cache don't change.
> There are several applicable resolutions:
> # There should be error thrown by Teiid, that this is not allowed operation
> # There should be update count 0 returned
> # There should be change in JDG cache, effectively squashing the 6 rows into single one
> # There should be error thrown by Teiid, that there is duplicate PK value (this is not something Teiid usually enforces)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months