[JBoss JIRA] (TEIID-3091) Excel translator issue: FIRST_DATA_ROW_NUMBER option not working
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3091?page=com.atlassian.jira.plugin... ]
Ramesh Reddy resolved TEIID-3091.
---------------------------------
Resolution: Duplicate Issue
Duplicate of TEIID-3089
> Excel translator issue: FIRST_DATA_ROW_NUMBER option not working
> -----------------------------------------------------------------
>
> Key: TEIID-3091
> URL: https://issues.jboss.org/browse/TEIID-3091
> Project: Teiid
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Misc. Connectors
> Affects Versions: 8.7.1
> Reporter: Van Halbert
> Assignee: Ramesh Reddy
> Attachments: excel.png, excel_row_number_issue.tiff
>
>
> The FIRST_DATA_ROW_NUMBER option not working, seeing the first row in the results, when using the following dynamic VDB definition:
> {code}
> <model name="OtherHoldings">
> <property name="importer.headerRowNumber" value="1"/>
> <property name="importer.ExcelFileName" value="otherholdings.xls"/>
> <source name="excelconnector" translator-name="excel" connection-jndi-name="java:/excel-file"/>
> <metadata type="DDL"><![CDATA[
> SET NAMESPACE 'http://www.teiid.org/translator/excel/2014' AS teiid_excel;
> CREATE FOREIGN TABLE Sheet1 (
> ROW_ID integer OPTIONS (SEARCHABLE 'All_Except_Like', "teiid_excel:CELL_NUMBER" 'ROW_ID'),
> FirstName string OPTIONS (SEARCHABLE 'Unsearchable', "teiid_excel:CELL_NUMBER" '1'),
> LastName string OPTIONS (SEARCHABLE 'Unsearchable', "teiid_excel:CELL_NUMBER" '2'),
> Age string OPTIONS (SEARCHABLE 'Unsearchable', "teiid_excel:CELL_NUMBER" '3'),
> CONSTRAINT PK0 PRIMARY KEY(ROW_ID)
> ) OPTIONS ("teiid_excel:FILE" 'otherholdings.xls', "teiid_excel:FIRST_DATA_ROW_NUMBER" '2');
> ]]> </metadata>
> </model>
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (TEIID-3091) Excel translator issue: FIRST_DATA_ROW_NUMBER option not working
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-3091?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-3091:
------------------------------------
Ok, that looks good.
> Excel translator issue: FIRST_DATA_ROW_NUMBER option not working
> -----------------------------------------------------------------
>
> Key: TEIID-3091
> URL: https://issues.jboss.org/browse/TEIID-3091
> Project: Teiid
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Misc. Connectors
> Affects Versions: 8.7.1
> Reporter: Van Halbert
> Assignee: Ramesh Reddy
> Attachments: excel.png, excel_row_number_issue.tiff
>
>
> The FIRST_DATA_ROW_NUMBER option not working, seeing the first row in the results, when using the following dynamic VDB definition:
> {code}
> <model name="OtherHoldings">
> <property name="importer.headerRowNumber" value="1"/>
> <property name="importer.ExcelFileName" value="otherholdings.xls"/>
> <source name="excelconnector" translator-name="excel" connection-jndi-name="java:/excel-file"/>
> <metadata type="DDL"><![CDATA[
> SET NAMESPACE 'http://www.teiid.org/translator/excel/2014' AS teiid_excel;
> CREATE FOREIGN TABLE Sheet1 (
> ROW_ID integer OPTIONS (SEARCHABLE 'All_Except_Like', "teiid_excel:CELL_NUMBER" 'ROW_ID'),
> FirstName string OPTIONS (SEARCHABLE 'Unsearchable', "teiid_excel:CELL_NUMBER" '1'),
> LastName string OPTIONS (SEARCHABLE 'Unsearchable', "teiid_excel:CELL_NUMBER" '2'),
> Age string OPTIONS (SEARCHABLE 'Unsearchable', "teiid_excel:CELL_NUMBER" '3'),
> CONSTRAINT PK0 PRIMARY KEY(ROW_ID)
> ) OPTIONS ("teiid_excel:FILE" 'otherholdings.xls', "teiid_excel:FIRST_DATA_ROW_NUMBER" '2');
> ]]> </metadata>
> </model>
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (TEIID-2914) Infinispan Connector didn't have the advanced searching option exposed
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2914?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2914:
---------------------------------------
This doesn't appear to have been done yet. Do you want me to alter the ra.xml files or is this being done as part of the other work?
> Infinispan Connector didn't have the advanced searching option exposed
> ----------------------------------------------------------------------
>
> Key: TEIID-2914
> URL: https://issues.jboss.org/browse/TEIID-2914
> Project: Teiid
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Misc. Connectors
> Affects Versions: 8.7, 8.7.1
> Reporter: Van Halbert
> Assignee: Steven Hawkins
>
> The advanced searching option (i.e, lucene searching) that is defined in the .rar was not being picked up in the connector.
> Also, it was incorrectly defined on the translator, because the translator cannot override how the cache is configured.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (TEIID-2909) Provide more info for TeiidPropertyDefinition marked 'isRequired' but with conditions
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2909?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2909.
-----------------------------------
Resolution: Deferred
Marking as deferred. The boolean metadata will suffice for now.
> Provide more info for TeiidPropertyDefinition marked 'isRequired' but with conditions
> -------------------------------------------------------------------------------------
>
> Key: TEIID-2909
> URL: https://issues.jboss.org/browse/TEIID-2909
> Project: Teiid
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: AdminApi
> Affects Versions: 8.4
> Reporter: Mark Drilling
> Assignee: Steven Hawkins
>
> For some data source types, there are associated propertyDefinitions that are marked 'required'. However, they are not always required.
> I'm referring to TeiidPropertyDefinition list returned by adminApi.getTemplatePropertyDefns(), for example.
> Google source is example of a source containing this type of property definition.
> https://docs.jboss.org/author/display/teiid84final/Google+Spreadsheet+Dat...
> For example 'RefreshToken' is marked as required, but it is only required based on the value of another property (AuthMethod).
> Can teiid provide these additional conditions along with the propertyDefinition? Without this information we are forced to hard-code the validation rules into our client application.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (TEIID-3074) NPE When using External Materialization management is use
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3074?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-3074:
-------------------------------------
Yes, the exception is swallowed and keeps repeating and fills out the log. I see that in this situation it consumes all the worker threads, so debugging was difficult . I was using two sources SOLR and MariaDB, and using externalized mat view with "Status" table in the MariaDB and mat view target in SOLR. It looked like it was trying to execute "MVStatus" procedure for each row, but I could be wrong, that may be due to NPE above. I can re-create pretty consistently. I did not see any other exception, MVStatus does return successfully.
> NPE When using External Materialization management is use
> ---------------------------------------------------------
>
> Key: TEIID-3074
> URL: https://issues.jboss.org/browse/TEIID-3074
> Project: Teiid
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Query Engine
> Affects Versions: 8.5
> Reporter: Ramesh Reddy
> Assignee: Steven Hawkins
> Attachments: debug_plan.txt, solr-integration-with-matview-vdb.xml
>
>
> When I was issuing query that has externalized materialization with management option to true, I am seeing NPE. Tried to see why NPE is occurring was not able to figure out (yet)
> {code}
> 14:37:50,269 ERROR [org.teiid.CONNECTOR] (Worker1_QueryProcessorQueue8477) 0z97J5OWq7x9 Connector worker process failed for atomic-request=0z97J5OWq7x9.7.1.4220: java.lang.NullPointerException
> at org.teiid.translator.jdbc.JDBCQueryExecution.next(JDBCQueryExecution.java:338)
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.handleBatch(ConnectorWorkItem.java:385) [teiid-engine-8.9.0.Alpha1-SNAPSHOT.jar:8.9.0.Alpha1-SNAPSHOT]
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.more(ConnectorWorkItem.java:203) [teiid-engine-8.9.0.Alpha1-SNAPSHOT.jar:8.9.0.Alpha1-SNAPSHOT]
> at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:301) [teiid-engine-8.9.0.Alpha1-SNAPSHOT.jar:8.9.0.Alpha1-SNAPSHOT]
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:110) [teiid-engine-8.9.0.Alpha1-SNAPSHOT.jar:8.9.0.Alpha1-SNAPSHOT]
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:107) [teiid-engine-8.9.0.Alpha1-SNAPSHOT.jar:8.9.0.Alpha1-SNAPSHOT]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_65]
> at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:58) [teiid-engine-8.9.0.Alpha1-SNAPSHOT.jar:8.9.0.Alpha1-SNAPSHOT]
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:274) [teiid-engine-8.9.0.Alpha1-SNAPSHOT.jar:8.9.0.Alpha1-SNAPSHOT]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) [teiid-engine-8.9.0.Alpha1-SNAPSHOT.jar:8.9.0.Alpha1-SNAPSHOT]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:214) [teiid-engine-8.9.0.Alpha1-SNAPSHOT.jar:8.9.0.Alpha1-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_65]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_65]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (TEIID-2892) OData buffers ALL rows from resultset before returning the first batch
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2892?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2892.
-----------------------------------
Resolution: Incomplete Description
Marking as incomplete description until a proposal is made on not enforcing order or providing alternative orderings.
> OData buffers ALL rows from resultset before returning the first batch
> ----------------------------------------------------------------------
>
> Key: TEIID-2892
> URL: https://issues.jboss.org/browse/TEIID-2892
> Project: Teiid
> Issue Type: Quality Risk
> Security Level: Public(Everyone can see)
> Components: OData
> Affects Versions: 8.4.1
> Environment: Tested with Jboss DV 6.0.0. GA (enterprise edition) on Apple OSX 10.9.2 and Oracle Java VM 1.7.0_51.
> Reporter: Patrick Deenen
> Assignee: Steven Hawkins
> Attachments: logfiles.zip
>
>
> OData doesn’t batch internally opposed to JDBC which does. E.g. when in JDBC a query is done with a large result, only the first 2048 rows are physically fetched from the source database and only the first 200 rows (depending on client application) are returned. But when the same query is executed by the use of Odata ALL rows in the result set are physically fetched by DV and stored in the buffer. Even with the default Odata fetch batch size of 256. This makes the Odata interface very inefficient for large query results where one only is interessed in the first 256 rows.
> Attached you can find two log files which show the problem.
> The Odata query used is:
> http://localhost:8080/odata/PMA/EVENT_FACT?$filter=event_fact_id%20ge%207...
> Which is identical to the JDBC query used:
> select * from event_fact where event_fact_id between 747000000 and 747200000;
> In both cases the result contains 200.000 rows
> ODATA log information analysis (log file ’server start + odata batch 256.log’):
> row 4543 - 4657 - Start query
> row 4658 - 9030 - Read ALL results from result set and store them in buffer
> row 9031 - 9035 - Close DB connection
> row 9036 - 14647 - Clean buffers and create response?
> row 14648 - 14661 - return first batch and close connection
> JDBC log information analysis (log file ’server start + jdbc.log’):
> row 4925 - 5112 - Start query
> row 5113 - 5166 - Read ONLY the first 2048 results from result set and store them in buffer and return response
> row 5157 - 5214 - Close DB connection
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (TEIID-2949) Issue querying Google Spreadsheet
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2949?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2949.
-----------------------------------
Resolution: Done
>From the google issue, this appears to have been resolved from their side.
> Issue querying Google Spreadsheet
> ---------------------------------
>
> Key: TEIID-2949
> URL: https://issues.jboss.org/browse/TEIID-2949
> Project: Teiid
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Misc. Connectors
> Affects Versions: 8.4.1
> Reporter: Van Halbert
> Assignee: Steven Hawkins
>
> Issue querying google spreadsheet:
> Steps to Reproduce:
> 1. configure resource adaptor for google in standalone.xml
> <resource-adapter id="google">
> <module slot="main" id="org.jboss.teiid.resource-adapter.google"/>
> <transaction-support>NoTransaction</transaction-support>
> <connection-definitions>
> <connection-definition class-name="org.teiid.resource.adapter.google.SpreadsheetManagedConnectionFactory" jndi-name="java:/google" enabled="true" use-java-context="true" pool-name="google">
> <config-property name="AuthMethod">
> ClientLogin
> </config-property>
> <config-property name="SpreadsheetName">
> testsheet
> </config-property>
> <config-property name="BatchSize">
> 4096
> </config-property>
> <config-property name="Username">
> hokuda.test(a)gmail.com
> </config-property>
> <config-property name="Password">
> passpassw
> </config-property>
> </connection-definition>
> </connection-definitions>
> </resource-adapter>
> 2. deploy dynamic vdb
> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> <vdb name="test" version="1">
> <description>Dynamic Google Spreadsheet VDB</description>
> <model name="google">
> <source name="google-spreadsheet" translator-name="google-spreadsheet" connection-jndi-name="java:/google"/>
> </model>
> </vdb>
> 3. you get an exception
> 16:59:34,429 WARN [org.teiid.RUNTIME] (teiid-async-threads - 1) TEIID50036 VDB test.1 model "google" metadata failed to load. Reas
> on:Error when getting batch 404:Not Found: org.teiid.resource.adapter.google.common.SpreadsheetOperationException: Error when getti
> ng batch 404:Not Found
> at org.teiid.resource.adapter.google.dataprotocol.GoogleDataProtocolAPI$DataProtocolQueryStrategy.executeAndParse(GoogleDat
> aProtocolAPI.java:248)
> at org.teiid.resource.adapter.google.dataprotocol.GoogleDataProtocolAPI$DataProtocolQueryStrategy.getResultsBatch(GoogleDat
> aProtocolAPI.java:163)
> at org.teiid.resource.adapter.google.dataprotocol.GoogleDataProtocolAPI.getMetadata(GoogleDataProtocolAPI.java:109)
> at org.teiid.resource.adapter.google.gdata.SpreadsheetMetadataExtractor.extractMetadata(SpreadsheetMetadataExtractor.java:7
> 4)
> at org.teiid.resource.adapter.google.SpreadsheetConnectionImpl.getSpreadsheetInfo(SpreadsheetConnectionImpl.java:147)
> at org.teiid.translator.google.SpreadsheetExecutionFactory.getMetadata(SpreadsheetExecutionFactory.java:71)
> at org.teiid.translator.google.SpreadsheetExecutionFactory.getMetadata(SpreadsheetExecutionFactory.java:45)
> at org.teiid.query.metadata.NativeMetadataRepository.loadMetadata(NativeMetadataRepository.java:61) [teiid-engine-8.4.1-red
> hat-7.jar:8.4.1-redhat-7]
> at org.teiid.query.metadata.ChainingMetadataRepository.loadMetadata(ChainingMetadataRepository.java:55) [teiid-engine-8.4.1
> -redhat-7.jar:8.4.1-redhat-7]
> at org.teiid.jboss.VDBService$6.run(VDBService.java:397) [teiid-jboss-integration-8.4.1-redhat-7.jar:8.4.1-redhat-7]
> at org.teiid.jboss.VDBService$7.run(VDBService.java:444) [teiid-jboss-integration-8.4.1-redhat-7.jar:8.4.1-redhat-7]
> at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)
> at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:806)
> at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45)
> at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:826)
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> Here's a reference to the google issue that's causing our issue:
> https://code.google.com/p/google-visualization-api-issues/issues/detail?i...
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (TEIID-2892) OData buffers ALL rows from resultset before returning the first batch
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2892?page=com.atlassian.jira.plugin... ]
Steven Hawkins edited comment on TEIID-2892 at 8/18/14 2:31 PM:
----------------------------------------------------------------
Changing this issue to a quality risk. We can address as an enhancement if a specific proposal is made.
was (Author: shawkins):
Changing this issue to a quality risk. When can address as an enhancement if a specific proposal is made.
> OData buffers ALL rows from resultset before returning the first batch
> ----------------------------------------------------------------------
>
> Key: TEIID-2892
> URL: https://issues.jboss.org/browse/TEIID-2892
> Project: Teiid
> Issue Type: Quality Risk
> Security Level: Public(Everyone can see)
> Components: OData
> Affects Versions: 8.4.1
> Environment: Tested with Jboss DV 6.0.0. GA (enterprise edition) on Apple OSX 10.9.2 and Oracle Java VM 1.7.0_51.
> Reporter: Patrick Deenen
> Assignee: Steven Hawkins
> Attachments: logfiles.zip
>
>
> OData doesn’t batch internally opposed to JDBC which does. E.g. when in JDBC a query is done with a large result, only the first 2048 rows are physically fetched from the source database and only the first 200 rows (depending on client application) are returned. But when the same query is executed by the use of Odata ALL rows in the result set are physically fetched by DV and stored in the buffer. Even with the default Odata fetch batch size of 256. This makes the Odata interface very inefficient for large query results where one only is interessed in the first 256 rows.
> Attached you can find two log files which show the problem.
> The Odata query used is:
> http://localhost:8080/odata/PMA/EVENT_FACT?$filter=event_fact_id%20ge%207...
> Which is identical to the JDBC query used:
> select * from event_fact where event_fact_id between 747000000 and 747200000;
> In both cases the result contains 200.000 rows
> ODATA log information analysis (log file ’server start + odata batch 256.log’):
> row 4543 - 4657 - Start query
> row 4658 - 9030 - Read ALL results from result set and store them in buffer
> row 9031 - 9035 - Close DB connection
> row 9036 - 14647 - Clean buffers and create response?
> row 14648 - 14661 - return first batch and close connection
> JDBC log information analysis (log file ’server start + jdbc.log’):
> row 4925 - 5112 - Start query
> row 5113 - 5166 - Read ONLY the first 2048 results from result set and store them in buffer and return response
> row 5157 - 5214 - Close DB connection
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (TEIID-3036) Update CXF to current version (3.0.0)
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3036?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3036:
---------------------------------------
Ramesh has addressed the inconsistency with the CXF versions. 2.7.11 support will be ensured if/when community can move to a later EAP target or Wildfly 8.1. In any case version 3 support will be quite a ways off.
> Update CXF to current version (3.0.0)
> -------------------------------------
>
> Key: TEIID-3036
> URL: https://issues.jboss.org/browse/TEIID-3036
> Project: Teiid
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Embedded
> Affects Versions: 8.8
> Reporter: Gary Gregory
> Assignee: Steven Hawkins
>
> In the same vein as TEIID-3030, we embed CXF and Teiid in our server. We use CXF 2.7.10 and are about to update to 3.0.0. At worse, we'll go to 2.7.11 as an interim step to 3.0.0.
> Teiid embedded delivers CXF 2.6.6 for web services support.
> It would be great if we could get Teiid to the latest and greatest from CXF so we can all live in the same space without being forced to deal with any incompatibilities or class loader hacks.
> Thank you,
> Gary
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (TEIID-3091) Excel translator issue: FIRST_DATA_ROW_NUMBER option not working
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3091?page=com.atlassian.jira.plugin... ]
Ramesh Reddy updated TEIID-3091:
--------------------------------
Attachment: excel.png
This is what I see after fixing the TEIID-3089
> Excel translator issue: FIRST_DATA_ROW_NUMBER option not working
> -----------------------------------------------------------------
>
> Key: TEIID-3091
> URL: https://issues.jboss.org/browse/TEIID-3091
> Project: Teiid
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Misc. Connectors
> Affects Versions: 8.7.1
> Reporter: Van Halbert
> Assignee: Ramesh Reddy
> Attachments: excel.png, excel_row_number_issue.tiff
>
>
> The FIRST_DATA_ROW_NUMBER option not working, seeing the first row in the results, when using the following dynamic VDB definition:
> {code}
> <model name="OtherHoldings">
> <property name="importer.headerRowNumber" value="1"/>
> <property name="importer.ExcelFileName" value="otherholdings.xls"/>
> <source name="excelconnector" translator-name="excel" connection-jndi-name="java:/excel-file"/>
> <metadata type="DDL"><![CDATA[
> SET NAMESPACE 'http://www.teiid.org/translator/excel/2014' AS teiid_excel;
> CREATE FOREIGN TABLE Sheet1 (
> ROW_ID integer OPTIONS (SEARCHABLE 'All_Except_Like', "teiid_excel:CELL_NUMBER" 'ROW_ID'),
> FirstName string OPTIONS (SEARCHABLE 'Unsearchable', "teiid_excel:CELL_NUMBER" '1'),
> LastName string OPTIONS (SEARCHABLE 'Unsearchable', "teiid_excel:CELL_NUMBER" '2'),
> Age string OPTIONS (SEARCHABLE 'Unsearchable', "teiid_excel:CELL_NUMBER" '3'),
> CONSTRAINT PK0 PRIMARY KEY(ROW_ID)
> ) OPTIONS ("teiid_excel:FILE" 'otherholdings.xls', "teiid_excel:FIRST_DATA_ROW_NUMBER" '2');
> ]]> </metadata>
> </model>
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months