[JBoss JIRA] (TEIID-5071) Teiid designer Odata4 model import fails to load metadata and throws java.lang.NullPointerException
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-5071?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-5071:
-------------------------------------
I believe there is already one, one defines the OData service version and another for metadata version. They were specific to call out in v4.01. For now, the documentation on our side is needed.
> Teiid designer Odata4 model import fails to load metadata and throws java.lang.NullPointerException
> ---------------------------------------------------------------------------------------------------
>
> Key: TEIID-5071
> URL: https://issues.jboss.org/browse/TEIID-5071
> Project: Teiid
> Issue Type: Bug
> Components: OData
> Affects Versions: 8.12.12.6_3
> Reporter: Colin Mondesir
> Assignee: Steven Hawkins
>
> The odata4 translator throws a NPE when the designer attempts to import model.
> 08:55:36,424 WARN [org.teiid.RUNTIME] (teiid-async-threads - 3) TEIID50036 VDB importVDB1.1 model "importVDB1SrcModel" metadata failed to load. Reason:java.lang.NullPointerException: java.lang.NullPointerException
> at org.teiid.translator.odata4.ODataMetadataProcessor.addPrimaryKey(ODataMetadataProcessor.java:331)
> at org.teiid.translator.odata4.ODataMetadataProcessor.addEntityTypeProperties(ODataMetadataProcessor.java:243)
> at org.teiid.translator.odata4.ODataMetadataProcessor.addTable(ODataMetadataProcessor.java:219)
> at org.teiid.translator.odata4.ODataMetadataProcessor.getMetadata(ODataMetadataProcessor.java:122)
> at org.teiid.translator.odata4.ODataMetadataProcessor.process(ODataMetadataProcessor.java:105)
> at org.teiid.translator.odata4.ODataExecutionFactory.getMetadata(ODataExecutionFactory.java:119)
> at org.teiid.translator.odata4.ODataExecutionFactory.getMetadata(ODataExecutionFactory.java:69)
> at org.teiid.query.metadata.NativeMetadataRepository.getMetadata(NativeMetadataRepository.java:96) [teiid-engine-8.12.10.6_3-redhat-2.jar:8.12.10.6_3-redhat-2]
> at org.teiid.query.metadata.NativeMetadataRepository.loadMetadata(NativeMetadataRepository.java:62) [teiid-engine-8.12.10.6_3-redhat-2.jar:8.12.10.6_3-redhat-2]
> at org.teiid.query.metadata.ChainingMetadataRepository.loadMetadata(ChainingMetadataRepository.java:55) [teiid-engine-8.12.10.6_3-redhat-2.jar:8.12.10.6_3-redhat-2]
> at org.teiid.jboss.VDBService$6.run(VDBService.java:395) [teiid-jboss-integration-8.12.10.6_3-redhat-2.jar:8.12.10.6_3-redhat-2]
> at org.teiid.jboss.VDBService$7.run(VDBService.java:446) [teiid-jboss-integration-8.12.10.6_3-redhat-2.jar:8.12.10.6_3-redhat-2]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_60]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_60]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_60]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months
[JBoss JIRA] (TEIID-5072) Generated keys should be passed from triggers
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-5072?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-5072:
-------------------------------------
Since you are saying the inherent case, how about the explicit trigger but single insert statement case? I guess I am thinking each time insert happens Key is populated unless user captured in another variable.
> Generated keys should be passed from triggers
> ---------------------------------------------
>
> Key: TEIID-5072
> URL: https://issues.jboss.org/browse/TEIID-5072
> Project: Teiid
> Issue Type: Sub-task
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 10.0
>
>
> In the context of an update trigger we should be able to convey the generated keys to the caller. In the case where only a single insert occurs, this should be automatic. Otherwise we'll need functions/variables to get/set the generated keys in the procedure. For example see the LAST_INSERT_ID function on mysql.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months
[JBoss JIRA] (TEIID-5071) Teiid designer Odata4 model import fails to load metadata and throws java.lang.NullPointerException
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5071?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5071:
---------------------------------------
[~rareddy] So then there needs to be an olingo issue logged to expose/check the DataServiceVersion properties, and we need to document explicitly that this translator cannot be used against a v 1-3 service.
> Teiid designer Odata4 model import fails to load metadata and throws java.lang.NullPointerException
> ---------------------------------------------------------------------------------------------------
>
> Key: TEIID-5071
> URL: https://issues.jboss.org/browse/TEIID-5071
> Project: Teiid
> Issue Type: Bug
> Components: OData
> Affects Versions: 8.12.12.6_3
> Reporter: Colin Mondesir
> Assignee: Steven Hawkins
>
> The odata4 translator throws a NPE when the designer attempts to import model.
> 08:55:36,424 WARN [org.teiid.RUNTIME] (teiid-async-threads - 3) TEIID50036 VDB importVDB1.1 model "importVDB1SrcModel" metadata failed to load. Reason:java.lang.NullPointerException: java.lang.NullPointerException
> at org.teiid.translator.odata4.ODataMetadataProcessor.addPrimaryKey(ODataMetadataProcessor.java:331)
> at org.teiid.translator.odata4.ODataMetadataProcessor.addEntityTypeProperties(ODataMetadataProcessor.java:243)
> at org.teiid.translator.odata4.ODataMetadataProcessor.addTable(ODataMetadataProcessor.java:219)
> at org.teiid.translator.odata4.ODataMetadataProcessor.getMetadata(ODataMetadataProcessor.java:122)
> at org.teiid.translator.odata4.ODataMetadataProcessor.process(ODataMetadataProcessor.java:105)
> at org.teiid.translator.odata4.ODataExecutionFactory.getMetadata(ODataExecutionFactory.java:119)
> at org.teiid.translator.odata4.ODataExecutionFactory.getMetadata(ODataExecutionFactory.java:69)
> at org.teiid.query.metadata.NativeMetadataRepository.getMetadata(NativeMetadataRepository.java:96) [teiid-engine-8.12.10.6_3-redhat-2.jar:8.12.10.6_3-redhat-2]
> at org.teiid.query.metadata.NativeMetadataRepository.loadMetadata(NativeMetadataRepository.java:62) [teiid-engine-8.12.10.6_3-redhat-2.jar:8.12.10.6_3-redhat-2]
> at org.teiid.query.metadata.ChainingMetadataRepository.loadMetadata(ChainingMetadataRepository.java:55) [teiid-engine-8.12.10.6_3-redhat-2.jar:8.12.10.6_3-redhat-2]
> at org.teiid.jboss.VDBService$6.run(VDBService.java:395) [teiid-jboss-integration-8.12.10.6_3-redhat-2.jar:8.12.10.6_3-redhat-2]
> at org.teiid.jboss.VDBService$7.run(VDBService.java:446) [teiid-jboss-integration-8.12.10.6_3-redhat-2.jar:8.12.10.6_3-redhat-2]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_60]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_60]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_60]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months
[JBoss JIRA] (TEIID-5071) Teiid designer Odata4 model import fails to load metadata and throws java.lang.NullPointerException
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-5071?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-5071:
-------------------------------------
[~shawkins] Not currently. Currently V2 and V4 are two completely separate code bases in Teiid, user must have knowledge about which version they are using. Going forward with V4 we would have to check the versions, but next version V4.01 is still in public review as of today. When we implement that we will on V4 code base.
> Teiid designer Odata4 model import fails to load metadata and throws java.lang.NullPointerException
> ---------------------------------------------------------------------------------------------------
>
> Key: TEIID-5071
> URL: https://issues.jboss.org/browse/TEIID-5071
> Project: Teiid
> Issue Type: Bug
> Components: OData
> Affects Versions: 8.12.12.6_3
> Reporter: Colin Mondesir
> Assignee: Steven Hawkins
>
> The odata4 translator throws a NPE when the designer attempts to import model.
> 08:55:36,424 WARN [org.teiid.RUNTIME] (teiid-async-threads - 3) TEIID50036 VDB importVDB1.1 model "importVDB1SrcModel" metadata failed to load. Reason:java.lang.NullPointerException: java.lang.NullPointerException
> at org.teiid.translator.odata4.ODataMetadataProcessor.addPrimaryKey(ODataMetadataProcessor.java:331)
> at org.teiid.translator.odata4.ODataMetadataProcessor.addEntityTypeProperties(ODataMetadataProcessor.java:243)
> at org.teiid.translator.odata4.ODataMetadataProcessor.addTable(ODataMetadataProcessor.java:219)
> at org.teiid.translator.odata4.ODataMetadataProcessor.getMetadata(ODataMetadataProcessor.java:122)
> at org.teiid.translator.odata4.ODataMetadataProcessor.process(ODataMetadataProcessor.java:105)
> at org.teiid.translator.odata4.ODataExecutionFactory.getMetadata(ODataExecutionFactory.java:119)
> at org.teiid.translator.odata4.ODataExecutionFactory.getMetadata(ODataExecutionFactory.java:69)
> at org.teiid.query.metadata.NativeMetadataRepository.getMetadata(NativeMetadataRepository.java:96) [teiid-engine-8.12.10.6_3-redhat-2.jar:8.12.10.6_3-redhat-2]
> at org.teiid.query.metadata.NativeMetadataRepository.loadMetadata(NativeMetadataRepository.java:62) [teiid-engine-8.12.10.6_3-redhat-2.jar:8.12.10.6_3-redhat-2]
> at org.teiid.query.metadata.ChainingMetadataRepository.loadMetadata(ChainingMetadataRepository.java:55) [teiid-engine-8.12.10.6_3-redhat-2.jar:8.12.10.6_3-redhat-2]
> at org.teiid.jboss.VDBService$6.run(VDBService.java:395) [teiid-jboss-integration-8.12.10.6_3-redhat-2.jar:8.12.10.6_3-redhat-2]
> at org.teiid.jboss.VDBService$7.run(VDBService.java:446) [teiid-jboss-integration-8.12.10.6_3-redhat-2.jar:8.12.10.6_3-redhat-2]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_60]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_60]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_60]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months
[JBoss JIRA] (TEIID-5039) Couchbase document type definition for a table
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5039?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-5039:
----------------------------------
Fix Version/s: 9.3.4
(was: 9.3.3)
This is being addressed with new commits, so for 9.3.3 the workaround for bulk is to include the type.
> Couchbase document type definition for a table
> ----------------------------------------------
>
> Key: TEIID-5039
> URL: https://issues.jboss.org/browse/TEIID-5039
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Reporter: Jan Stastny
> Assignee: Steven Hawkins
> Priority: Blocker
> Fix For: 10.0, 8.12.x-6.4, 9.3.4
>
>
> If a table is tight to a single document type, there shouldn't be need for explicit type column assignment when inserting into that table.
> With a vdb:
> {code:sql|title=DDL}
> CREATE FOREIGN TABLE SmallA (
> documentID string PRIMARY KEY,
> type string OPTIONS (NAMEINSOURCE '`type`'),
> FloatNum float OPTIONS (NAMEINSOURCE '`FloatNum`'),
> BigIntegerValue biginteger OPTIONS (NAMEINSOURCE '`BigIntegerValue`'),
> StringKey string OPTIONS (NAMEINSOURCE '`StringKey`'),
> CharValue string OPTIONS (NAMEINSOURCE '`CharValue`'),
> LongNum long OPTIONS (NAMEINSOURCE '`LongNum`'),
> DoubleNum double OPTIONS (NAMEINSOURCE '`DoubleNum`'),
> ObjectValue string OPTIONS (NAMEINSOURCE '`ObjectValue`'),
> ShortValue integer OPTIONS (NAMEINSOURCE '`ShortValue`'),
> BigDecimalValue bigdecimal OPTIONS (NAMEINSOURCE '`BigDecimalValue`'),
> DateValue string OPTIONS (NAMEINSOURCE '`DateValue`'),
> BooleanValue boolean OPTIONS (NAMEINSOURCE '`BooleanValue`'),
> TimestampValue string OPTIONS (NAMEINSOURCE '`TimestampValue`'),
> ByteNum integer OPTIONS (NAMEINSOURCE '`ByteNum`'),
> StringNum string OPTIONS (NAMEINSOURCE '`StringNum`'),
> TimeValue string OPTIONS (NAMEINSOURCE '`TimeValue`'),
> IntNum integer OPTIONS (NAMEINSOURCE '`IntNum`')
> ) OPTIONS (NAMEINSOURCE '`dvqe_crud`', UPDATABLE TRUE, "teiid_couchbase:ISARRAYTABLE" 'false', "teiid_couchbase:NAMEDTYPEPAIR" '`type`:''SmallA''');
> {code}
> I'd like to insert using such query:
> {code:sql|title=query}
> INSERT INTO Source.SmallA (documentID, StringKey, IntNum, StringNum) VALUES (1, '1', 1, '1');
> {code}
> And then getting the value back using
> {code:sql|title=query_select}
> SELECT * FROM Source.SmallA
> {code}
> to see the row I inserted.
> Everything without the need to explicitly set 'type' column for the insert query.
> There is missing 1-to-1 relation between a defined FOREIGN table and a document type in couchbase. (When I INSERT into a table in Teiid, there should be clear distiction about what type of document I am inserting and to what keyspace). Possibly the OPTION "teiid_couchbase:NAMEDTYPEPAIR" can serve this purpose, if it works that way for selects, why not for inserts.
> I see this as an usability blocker, when user has to set 'type' explicitly in every single insert.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months
[JBoss JIRA] (TEIID-5072) Generated keys should be passed from triggers
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5072?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5072:
---------------------------------------
> I did not understand the need for the generated_key? shouldn't this be automatic when the insert is finished Key group is populated?
No, it would not be automatic unless we are in the inherent case. Here the trigger could contain n number of inserts and a view transformation that doesn't clearly map the pk value. Rather than try to infer what insert(s) map appropriately, it's up to the user to associate the value.
> The next question is how can we push this Key back into JDBC resultset?
Do you mean Statement.getGeneratedKeys? That would be the outcome of this yes.
> Generated keys should be passed from triggers
> ---------------------------------------------
>
> Key: TEIID-5072
> URL: https://issues.jboss.org/browse/TEIID-5072
> Project: Teiid
> Issue Type: Sub-task
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 10.0
>
>
> In the context of an update trigger we should be able to convey the generated keys to the caller. In the case where only a single insert occurs, this should be automatic. Otherwise we'll need functions/variables to get/set the generated keys in the procedure. For example see the LAST_INSERT_ID function on mysql.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months
[JBoss JIRA] (TEIID-5072) Generated keys should be passed from triggers
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-5072?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-5072:
-------------------------------------
I like the variable group "Key", so it will have all the columns of a key columns of the view. I did not understand the need for the generated_key? shouldn't this be automatic when the insert is finished Key group is populated?
The next question is how can we push this Key back into JDBC resultset?
> Generated keys should be passed from triggers
> ---------------------------------------------
>
> Key: TEIID-5072
> URL: https://issues.jboss.org/browse/TEIID-5072
> Project: Teiid
> Issue Type: Sub-task
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 10.0
>
>
> In the context of an update trigger we should be able to convey the generated keys to the caller. In the case where only a single insert occurs, this should be automatic. Otherwise we'll need functions/variables to get/set the generated keys in the procedure. For example see the LAST_INSERT_ID function on mysql.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months
[JBoss JIRA] (TEIID-5039) Couchbase document type definition for a table
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5039?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5039:
---------------------------------------
I wouldn't say broken in so much as it didn't work correctly before :) But yes this case should have been addressed as well.
> Couchbase document type definition for a table
> ----------------------------------------------
>
> Key: TEIID-5039
> URL: https://issues.jboss.org/browse/TEIID-5039
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Reporter: Jan Stastny
> Assignee: Steven Hawkins
> Priority: Blocker
> Fix For: 10.0, 8.12.x-6.4, 9.3.3
>
>
> If a table is tight to a single document type, there shouldn't be need for explicit type column assignment when inserting into that table.
> With a vdb:
> {code:sql|title=DDL}
> CREATE FOREIGN TABLE SmallA (
> documentID string PRIMARY KEY,
> type string OPTIONS (NAMEINSOURCE '`type`'),
> FloatNum float OPTIONS (NAMEINSOURCE '`FloatNum`'),
> BigIntegerValue biginteger OPTIONS (NAMEINSOURCE '`BigIntegerValue`'),
> StringKey string OPTIONS (NAMEINSOURCE '`StringKey`'),
> CharValue string OPTIONS (NAMEINSOURCE '`CharValue`'),
> LongNum long OPTIONS (NAMEINSOURCE '`LongNum`'),
> DoubleNum double OPTIONS (NAMEINSOURCE '`DoubleNum`'),
> ObjectValue string OPTIONS (NAMEINSOURCE '`ObjectValue`'),
> ShortValue integer OPTIONS (NAMEINSOURCE '`ShortValue`'),
> BigDecimalValue bigdecimal OPTIONS (NAMEINSOURCE '`BigDecimalValue`'),
> DateValue string OPTIONS (NAMEINSOURCE '`DateValue`'),
> BooleanValue boolean OPTIONS (NAMEINSOURCE '`BooleanValue`'),
> TimestampValue string OPTIONS (NAMEINSOURCE '`TimestampValue`'),
> ByteNum integer OPTIONS (NAMEINSOURCE '`ByteNum`'),
> StringNum string OPTIONS (NAMEINSOURCE '`StringNum`'),
> TimeValue string OPTIONS (NAMEINSOURCE '`TimeValue`'),
> IntNum integer OPTIONS (NAMEINSOURCE '`IntNum`')
> ) OPTIONS (NAMEINSOURCE '`dvqe_crud`', UPDATABLE TRUE, "teiid_couchbase:ISARRAYTABLE" 'false', "teiid_couchbase:NAMEDTYPEPAIR" '`type`:''SmallA''');
> {code}
> I'd like to insert using such query:
> {code:sql|title=query}
> INSERT INTO Source.SmallA (documentID, StringKey, IntNum, StringNum) VALUES (1, '1', 1, '1');
> {code}
> And then getting the value back using
> {code:sql|title=query_select}
> SELECT * FROM Source.SmallA
> {code}
> to see the row I inserted.
> Everything without the need to explicitly set 'type' column for the insert query.
> There is missing 1-to-1 relation between a defined FOREIGN table and a document type in couchbase. (When I INSERT into a table in Teiid, there should be clear distiction about what type of document I am inserting and to what keyspace). Possibly the OPTION "teiid_couchbase:NAMEDTYPEPAIR" can serve this purpose, if it works that way for selects, why not for inserts.
> I see this as an usability blocker, when user has to set 'type' explicitly in every single insert.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months
[JBoss JIRA] (TEIID-5039) Couchbase document type definition for a table
by Jan Stastny (JIRA)
[ https://issues.jboss.org/browse/TEIID-5039?page=com.atlassian.jira.plugin... ]
Jan Stastny commented on TEIID-5039:
------------------------------------
[~shawkins] Bulk update was brokend by this fix I believe.
For query:
{code:sql|title=query}
INSERT INTO Source.smallA(documentId,StringKey) VALUES(3,'3'),(4,'4'),(5,'5')
{code}
I get:
{code:title=server.log}
14:43:13,773 ERROR [org.teiid.CONNECTOR] (Worker0_QueryProcessorQueue5) Connector worker process failed for atomic-request=lzmsLg5FtNZI.3.0.3: org.teiid.core.TeiidRuntimeException: TEIID29007 Mismatch of bulk insert columns and parameter values, INSERT INTO `dvqe_crud` (documentID, `StringKey`) VALUES (?, ?)
at org.teiid.translator.couchbase.N1QLUpdateVisitor.appendBulkValues(N1QLUpdateVisitor.java:201) [translator-couchbase-8.12.11.6_4.jar:8.12.11.6_4]
at org.teiid.translator.couchbase.N1QLUpdateVisitor.visit(N1QLUpdateVisitor.java:163) [translator-couchbase-8.12.11.6_4.jar:8.12.11.6_4]
at org.teiid.language.Insert.acceptVisitor(Insert.java:57) [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.couchbase.CouchbaseUpdateExecution.execute(CouchbaseUpdateExecution.java:52) [translator-couchbase-8.12.11.6_4.jar:8.12.11.6_4]
at org.teiid.dqp.internal.datamgr.ConnectorWorkItem$1.execute(ConnectorWorkItem.java:401)
at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.execute(ConnectorWorkItem.java:363)
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)
at com.sun.proxy.$Proxy79.execute(Unknown Source)
at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:306)
at org.teiid.dqp.internal.process.DataTierTupleSource.nextTuple(DataTierTupleSource.java:142)
at org.teiid.query.processor.relational.ProjectIntoNode.checkExitConditions(ProjectIntoNode.java:264)
at org.teiid.query.processor.relational.ProjectIntoNode.nextBatchDirect(ProjectIntoNode.java:234)
at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:281)
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:472)
at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:348)
at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51)
at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:274)
at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:280)
at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119)
at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210)
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]
{code}
> Couchbase document type definition for a table
> ----------------------------------------------
>
> Key: TEIID-5039
> URL: https://issues.jboss.org/browse/TEIID-5039
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Reporter: Jan Stastny
> Assignee: Steven Hawkins
> Priority: Blocker
> Fix For: 10.0, 8.12.x-6.4, 9.3.3
>
>
> If a table is tight to a single document type, there shouldn't be need for explicit type column assignment when inserting into that table.
> With a vdb:
> {code:sql|title=DDL}
> CREATE FOREIGN TABLE SmallA (
> documentID string PRIMARY KEY,
> type string OPTIONS (NAMEINSOURCE '`type`'),
> FloatNum float OPTIONS (NAMEINSOURCE '`FloatNum`'),
> BigIntegerValue biginteger OPTIONS (NAMEINSOURCE '`BigIntegerValue`'),
> StringKey string OPTIONS (NAMEINSOURCE '`StringKey`'),
> CharValue string OPTIONS (NAMEINSOURCE '`CharValue`'),
> LongNum long OPTIONS (NAMEINSOURCE '`LongNum`'),
> DoubleNum double OPTIONS (NAMEINSOURCE '`DoubleNum`'),
> ObjectValue string OPTIONS (NAMEINSOURCE '`ObjectValue`'),
> ShortValue integer OPTIONS (NAMEINSOURCE '`ShortValue`'),
> BigDecimalValue bigdecimal OPTIONS (NAMEINSOURCE '`BigDecimalValue`'),
> DateValue string OPTIONS (NAMEINSOURCE '`DateValue`'),
> BooleanValue boolean OPTIONS (NAMEINSOURCE '`BooleanValue`'),
> TimestampValue string OPTIONS (NAMEINSOURCE '`TimestampValue`'),
> ByteNum integer OPTIONS (NAMEINSOURCE '`ByteNum`'),
> StringNum string OPTIONS (NAMEINSOURCE '`StringNum`'),
> TimeValue string OPTIONS (NAMEINSOURCE '`TimeValue`'),
> IntNum integer OPTIONS (NAMEINSOURCE '`IntNum`')
> ) OPTIONS (NAMEINSOURCE '`dvqe_crud`', UPDATABLE TRUE, "teiid_couchbase:ISARRAYTABLE" 'false', "teiid_couchbase:NAMEDTYPEPAIR" '`type`:''SmallA''');
> {code}
> I'd like to insert using such query:
> {code:sql|title=query}
> INSERT INTO Source.SmallA (documentID, StringKey, IntNum, StringNum) VALUES (1, '1', 1, '1');
> {code}
> And then getting the value back using
> {code:sql|title=query_select}
> SELECT * FROM Source.SmallA
> {code}
> to see the row I inserted.
> Everything without the need to explicitly set 'type' column for the insert query.
> There is missing 1-to-1 relation between a defined FOREIGN table and a document type in couchbase. (When I INSERT into a table in Teiid, there should be clear distiction about what type of document I am inserting and to what keyspace). Possibly the OPTION "teiid_couchbase:NAMEDTYPEPAIR" can serve this purpose, if it works that way for selects, why not for inserts.
> I see this as an usability blocker, when user has to set 'type' explicitly in every single insert.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months