May 2018 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-4520) Support for Exasol Connector

by Rafal Korytkowski (JIRA)

[ https://issues.jboss.org/browse/TEIID-4520?page=com.atlassian.jira.plugin... ] Rafal Korytkowski commented on TEIID-4520: ------------------------------------------ Even though I haven't found it being documented anywhere "SELECT IntNum FROM DVQE.SmallA ORDER BY IntNum NULLS FIRST" works for Exasol so I think we'll add "NULLS FIRST" to "ORDER BY" by in TEIID. > Support for Exasol Connector > ---------------------------- > > Key: TEIID-4520 > URL: https://issues.jboss.org/browse/TEIID-4520 > Project: Teiid > Issue Type: Feature Request > Components: Misc. Connectors > Affects Versions: 9.x > Reporter: Van Halbert > Assignee: Andrej Šmigala > Fix For: 10.x, Open To Community > > > Requesting support for Exasol Connector -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4520) Support for Exasol Connector

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4520?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-4520: --------------------------------------- > Any suggestions on what would be the best fix? TEIID-5339 should address this. In some cases we have automatically added IS NOT NULL predicates to filter values, but that is not yet being done for merge sort joins. > Support for Exasol Connector > ---------------------------- > > Key: TEIID-4520 > URL: https://issues.jboss.org/browse/TEIID-4520 > Project: Teiid > Issue Type: Feature Request > Components: Misc. Connectors > Affects Versions: 9.x > Reporter: Van Halbert > Assignee: Andrej Šmigala > Fix For: 10.x, Open To Community > > > Requesting support for Exasol Connector -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4520) Support for Exasol Connector

by Rafal Korytkowski (JIRA)

[ https://issues.jboss.org/browse/TEIID-4520?page=com.atlassian.jira.plugin... ] Rafal Korytkowski commented on TEIID-4520: ------------------------------------------ I've identified the issue to be related to NULL sorting. Resolving this issue will most likely fix hundred of failing tests as they seem to be related. By default Exasol returns NULLs as last in ascending order as opposed to other DBs like MySQL, PostgreSQL, etc. Teiid expects the revert. It's why the verification step fails in the join query from above. I was looking for a way to change the sort behavior in Exasol, but it seems it's not possible. e.g. SELECT BigIntegerValue FROM BQT1.SmallA ORDER BY BigIntegerValue has the following processing plan (not yet sure why convert kicks in, any hints?): LimitNode(0) output=[convert(BigIntegerValue, biginteger)] limit 100 SortNode(1) output=[convert(BigIntegerValue, biginteger)] [SORT] [convert(BigIntegerValue, biginteger)] ProjectNode(2) output=[convert(BigIntegerValue, biginteger)] [convert(BigIntegerValue, biginteger)] AccessNode(3) output=[BigIntegerValue] SELECT g_0.BigIntegerValue FROM Source.smalla AS g_0 whereas SELECT BigDecimalValue FROM BQT1.SmallA ORDER BY BigDecimalValue: AccessNode(0) output=[BigDecimalValue] SELECT g_0.BigDecimalValue AS c_0 FROM Source.smalla AS g_0 ORDER BY c_0 LIMIT 100 In the first case my understanding is that SORT is applied on the teiid level, thus I see NULLs first, whereas in the second query it's passed directly to Exasol and NULLs come last. Any suggestions on what would be the best fix? Where there any cases like that in the past? > Support for Exasol Connector > ---------------------------- > > Key: TEIID-4520 > URL: https://issues.jboss.org/browse/TEIID-4520 > Project: Teiid > Issue Type: Feature Request > Components: Misc. Connectors > Affects Versions: 9.x > Reporter: Van Halbert > Assignee: Andrej Šmigala > Fix For: 10.x, Open To Community > > > Requesting support for Exasol Connector -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5322) create public ci

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-5322?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-5322: --------------------------------------- There are 1 or more dependencies that are not in maven central. The first from jboss developer is: Could not find artifact org.jboss.security:jboss-negotiation-spnego:jar:3.0.4.Final in central > create public ci > ---------------- > > Key: TEIID-5322 > URL: https://issues.jboss.org/browse/TEIID-5322 > Project: Teiid > Issue Type: Task > Components: Build/Kits > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 10.3 > > > Now that jboss public hudson has been decommissioned our jenkins build is fully private. We should promote a public ci build. > At least travis had issues with the size of the build log: https://docs.travis-ci.com/user/common-build-problems/ -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5339) Vertica join query fails due to unexpected ordering of intermediate results

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-5339?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-5339: --------------------------------------- > TEIID-4129 has then effectively broken this kind of join queries for vertica, right? For joins that contain null values on the affected types, yes this is preventing the successful completion. I can either look to expand the check that is being performed to be tolerant of nulls as high/last nulls won't change the results regardless. > Vertica join query fails due to unexpected ordering of intermediate results > --------------------------------------------------------------------------- > > Key: TEIID-5339 > URL: https://issues.jboss.org/browse/TEIID-5339 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 8.12.13.6_4 > Reporter: Jan Stastny > Assignee: Steven Hawkins > > Description of problem: > There is unexpected error caused by TEIID-4129 fix. > Error: > TEIID31202 Detected that an already sorted set of values was not in the expected order (typically UTF-16 / UCS-2). Please check the translator settings to ensure character columns used for joining are sorted as expected. > Query: > {code:sql} > SELECT BQT1.SmallA.IntKey, BQT2.SmallB.DoubleNum FROM BQT1.SmallA, BQT2.SmallB WHERE BQT1.SmallA.IntKey = BQT2.SmallB.DoubleNum > {code} > The property 'org.teiid.assumeMatchingCollation' is not set, thus default value is false. Teiid should resolve the issue with different ordering. > Pushed source commands: > 1. > {code:sql} > SELECT g_0."doublenum" AS c_0 FROM "dvqe"."public"."smallb" AS g_0 ORDER BY c_0 > {code} > 2. > {code:sql} > SELECT g_0."intkey" FROM "dvqe"."public"."smalla" AS g_0 > {code} > When I run the query 1 against actual vertica instance I get result as: > ---------- > | c_0 | > | ------ | > | -24.0 | > | -23.0 | > | -22.0 | > | -21.0 | > | -19.0 | > | -18.0 | > | -17.0 | > | -16.0 | > | -15.0 | > | -14.0 | > | -13.0 | > | -12.0 | > | -11.0 | > | -10.0 | > | -9.0 | > | -8.0 | > | -7.0 | > | -6.0 | > | -5.0 | > | -3.0 | > | -2.0 | > | -1.0 | > | 0.0 | > | 1.0 | > | 2.0 | > | 3.0 | > | 4.0 | > | 5.0 | > | 6.0 | > | 7.0 | > | 8.0 | > | 9.0 | > | 10.0 | > | 11.0 | > | 13.0 | > | 14.0 | > | 15.0 | > | 16.0 | > | 17.0 | > | 18.0 | > | 19.0 | > | 20.0 | > | 21.0 | > | 22.0 | > | 23.0 | > | 24.0 | > | 25.0 | > | <null> | > | <null> | > | <null> | > ---------- > Driver states the type is Float. > Query 2: > ---------- > | intkey | > | ------ | > | 0 | > | 1 | > | 2 | > | 3 | > | 4 | > | 5 | > | 6 | > | 7 | > | 8 | > | 9 | > | 10 | > | 11 | > | 12 | > | 13 | > | 14 | > | 15 | > | 16 | > | 17 | > | 18 | > | 19 | > | 20 | > | 21 | > | 22 | > | 23 | > | 24 | > | 25 | > | 26 | > | 27 | > | 28 | > | 29 | > | 30 | > | 31 | > | 32 | > | 33 | > | 34 | > | 35 | > | 36 | > | 37 | > | 38 | > | 39 | > | 40 | > | 41 | > | 42 | > | 43 | > | 44 | > | 45 | > | 46 | > | 47 | > | 48 | > | 49 | > ---------- -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5339) Vertica join query fails due to unexpected ordering of intermediate results

by Jan Stastny (JIRA)

[ https://issues.jboss.org/browse/TEIID-5339?page=com.atlassian.jira.plugin... ] Jan Stastny commented on TEIID-5339: ------------------------------------ TEIID-4129 has then effectively broken this kind of join queries for vertica, right? i.e. when join criteria contains columns where NULLs are sorted as largest values. > For FLOAT, BOOLEAN, CHAR, and VARCHAR, NULL appears last (largest) in ascending order. > Vertica join query fails due to unexpected ordering of intermediate results > --------------------------------------------------------------------------- > > Key: TEIID-5339 > URL: https://issues.jboss.org/browse/TEIID-5339 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 8.12.13.6_4 > Reporter: Jan Stastny > Assignee: Steven Hawkins > > Description of problem: > There is unexpected error caused by TEIID-4129 fix. > Error: > TEIID31202 Detected that an already sorted set of values was not in the expected order (typically UTF-16 / UCS-2). Please check the translator settings to ensure character columns used for joining are sorted as expected. > Query: > {code:sql} > SELECT BQT1.SmallA.IntKey, BQT2.SmallB.DoubleNum FROM BQT1.SmallA, BQT2.SmallB WHERE BQT1.SmallA.IntKey = BQT2.SmallB.DoubleNum > {code} > The property 'org.teiid.assumeMatchingCollation' is not set, thus default value is false. Teiid should resolve the issue with different ordering. > Pushed source commands: > 1. > {code:sql} > SELECT g_0."doublenum" AS c_0 FROM "dvqe"."public"."smallb" AS g_0 ORDER BY c_0 > {code} > 2. > {code:sql} > SELECT g_0."intkey" FROM "dvqe"."public"."smalla" AS g_0 > {code} > When I run the query 1 against actual vertica instance I get result as: > ---------- > | c_0 | > | ------ | > | -24.0 | > | -23.0 | > | -22.0 | > | -21.0 | > | -19.0 | > | -18.0 | > | -17.0 | > | -16.0 | > | -15.0 | > | -14.0 | > | -13.0 | > | -12.0 | > | -11.0 | > | -10.0 | > | -9.0 | > | -8.0 | > | -7.0 | > | -6.0 | > | -5.0 | > | -3.0 | > | -2.0 | > | -1.0 | > | 0.0 | > | 1.0 | > | 2.0 | > | 3.0 | > | 4.0 | > | 5.0 | > | 6.0 | > | 7.0 | > | 8.0 | > | 9.0 | > | 10.0 | > | 11.0 | > | 13.0 | > | 14.0 | > | 15.0 | > | 16.0 | > | 17.0 | > | 18.0 | > | 19.0 | > | 20.0 | > | 21.0 | > | 22.0 | > | 23.0 | > | 24.0 | > | 25.0 | > | <null> | > | <null> | > | <null> | > ---------- > Driver states the type is Float. > Query 2: > ---------- > | intkey | > | ------ | > | 0 | > | 1 | > | 2 | > | 3 | > | 4 | > | 5 | > | 6 | > | 7 | > | 8 | > | 9 | > | 10 | > | 11 | > | 12 | > | 13 | > | 14 | > | 15 | > | 16 | > | 17 | > | 18 | > | 19 | > | 20 | > | 21 | > | 22 | > | 23 | > | 24 | > | 25 | > | 26 | > | 27 | > | 28 | > | 29 | > | 30 | > | 31 | > | 32 | > | 33 | > | 34 | > | 35 | > | 36 | > | 37 | > | 38 | > | 39 | > | 40 | > | 41 | > | 42 | > | 43 | > | 44 | > | 45 | > | 46 | > | 47 | > | 48 | > | 49 | > ---------- -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5339) Vertica join query fails due to unexpected ordering of intermediate results

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-5339?page=com.atlassian.jira.plugin... ] Steven Hawkins edited comment on TEIID-5339 at 5/11/18 2:51 PM: ---------------------------------------------------------------- In this case the exception makes no difference in behavior as it's related to nulls appearing as high. So the issue here is that the vertica translator is reported the null order as low (the jdbc execution factory default), when it's actually high. It appears that vertica is more complicated that other sources as the ordering is type dependent: https://my.vertica.com/docs/8.1.x/HTML/index.htm#Authoring/AnalyzingData/... https://my.vertica.com/docs/7.2.x/HTML/index.htm#Authoring/SQLReferenceMa... was (Author: shawkins): In this case the exception makes no difference in behavior as it's related to nulls appearing as high. So the issue here is that the vertica translator is reported the null order as low (the jdbc execution factory default), when it's actually high. It appears that vertica is more complicated that other sources as the ordering is type dependent: https://my.vertica.com/docs/8.1.x/HTML/index.htm#Authoring/AnalyzingData/... > Vertica join query fails due to unexpected ordering of intermediate results > --------------------------------------------------------------------------- > > Key: TEIID-5339 > URL: https://issues.jboss.org/browse/TEIID-5339 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 8.12.13.6_4 > Reporter: Jan Stastny > Assignee: Steven Hawkins > > Description of problem: > There is unexpected error caused by TEIID-4129 fix. > Error: > TEIID31202 Detected that an already sorted set of values was not in the expected order (typically UTF-16 / UCS-2). Please check the translator settings to ensure character columns used for joining are sorted as expected. > Query: > {code:sql} > SELECT BQT1.SmallA.IntKey, BQT2.SmallB.DoubleNum FROM BQT1.SmallA, BQT2.SmallB WHERE BQT1.SmallA.IntKey = BQT2.SmallB.DoubleNum > {code} > The property 'org.teiid.assumeMatchingCollation' is not set, thus default value is false. Teiid should resolve the issue with different ordering. > Pushed source commands: > 1. > {code:sql} > SELECT g_0."doublenum" AS c_0 FROM "dvqe"."public"."smallb" AS g_0 ORDER BY c_0 > {code} > 2. > {code:sql} > SELECT g_0."intkey" FROM "dvqe"."public"."smalla" AS g_0 > {code} > When I run the query 1 against actual vertica instance I get result as: > ---------- > | c_0 | > | ------ | > | -24.0 | > | -23.0 | > | -22.0 | > | -21.0 | > | -19.0 | > | -18.0 | > | -17.0 | > | -16.0 | > | -15.0 | > | -14.0 | > | -13.0 | > | -12.0 | > | -11.0 | > | -10.0 | > | -9.0 | > | -8.0 | > | -7.0 | > | -6.0 | > | -5.0 | > | -3.0 | > | -2.0 | > | -1.0 | > | 0.0 | > | 1.0 | > | 2.0 | > | 3.0 | > | 4.0 | > | 5.0 | > | 6.0 | > | 7.0 | > | 8.0 | > | 9.0 | > | 10.0 | > | 11.0 | > | 13.0 | > | 14.0 | > | 15.0 | > | 16.0 | > | 17.0 | > | 18.0 | > | 19.0 | > | 20.0 | > | 21.0 | > | 22.0 | > | 23.0 | > | 24.0 | > | 25.0 | > | <null> | > | <null> | > | <null> | > ---------- > Driver states the type is Float. > Query 2: > ---------- > | intkey | > | ------ | > | 0 | > | 1 | > | 2 | > | 3 | > | 4 | > | 5 | > | 6 | > | 7 | > | 8 | > | 9 | > | 10 | > | 11 | > | 12 | > | 13 | > | 14 | > | 15 | > | 16 | > | 17 | > | 18 | > | 19 | > | 20 | > | 21 | > | 22 | > | 23 | > | 24 | > | 25 | > | 26 | > | 27 | > | 28 | > | 29 | > | 30 | > | 31 | > | 32 | > | 33 | > | 34 | > | 35 | > | 36 | > | 37 | > | 38 | > | 39 | > | 40 | > | 41 | > | 42 | > | 43 | > | 44 | > | 45 | > | 46 | > | 47 | > | 48 | > | 49 | > ---------- -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5339) Vertica join query fails due to unexpected ordering of intermediate results

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-5339?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-5339: --------------------------------------- In this case the exception makes no difference in behavior as it's related to nulls appearing as high. So the issue here is that the vertica translator is reported the null order as low (the jdbc execution factory default), when it's actually high. It appears that vertica is more complicated that other sources as the ordering is type dependent: https://my.vertica.com/docs/8.1.x/HTML/index.htm#Authoring/AnalyzingData/... > Vertica join query fails due to unexpected ordering of intermediate results > --------------------------------------------------------------------------- > > Key: TEIID-5339 > URL: https://issues.jboss.org/browse/TEIID-5339 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 8.12.13.6_4 > Reporter: Jan Stastny > Assignee: Steven Hawkins > > Description of problem: > There is unexpected error caused by TEIID-4129 fix. > Error: > TEIID31202 Detected that an already sorted set of values was not in the expected order (typically UTF-16 / UCS-2). Please check the translator settings to ensure character columns used for joining are sorted as expected. > Query: > {code:sql} > SELECT BQT1.SmallA.IntKey, BQT2.SmallB.DoubleNum FROM BQT1.SmallA, BQT2.SmallB WHERE BQT1.SmallA.IntKey = BQT2.SmallB.DoubleNum > {code} > The property 'org.teiid.assumeMatchingCollation' is not set, thus default value is false. Teiid should resolve the issue with different ordering. > Pushed source commands: > 1. > {code:sql} > SELECT g_0."doublenum" AS c_0 FROM "dvqe"."public"."smallb" AS g_0 ORDER BY c_0 > {code} > 2. > {code:sql} > SELECT g_0."intkey" FROM "dvqe"."public"."smalla" AS g_0 > {code} > When I run the query 1 against actual vertica instance I get result as: > ---------- > | c_0 | > | ------ | > | -24.0 | > | -23.0 | > | -22.0 | > | -21.0 | > | -19.0 | > | -18.0 | > | -17.0 | > | -16.0 | > | -15.0 | > | -14.0 | > | -13.0 | > | -12.0 | > | -11.0 | > | -10.0 | > | -9.0 | > | -8.0 | > | -7.0 | > | -6.0 | > | -5.0 | > | -3.0 | > | -2.0 | > | -1.0 | > | 0.0 | > | 1.0 | > | 2.0 | > | 3.0 | > | 4.0 | > | 5.0 | > | 6.0 | > | 7.0 | > | 8.0 | > | 9.0 | > | 10.0 | > | 11.0 | > | 13.0 | > | 14.0 | > | 15.0 | > | 16.0 | > | 17.0 | > | 18.0 | > | 19.0 | > | 20.0 | > | 21.0 | > | 22.0 | > | 23.0 | > | 24.0 | > | 25.0 | > | <null> | > | <null> | > | <null> | > ---------- > Driver states the type is Float. > Query 2: > ---------- > | intkey | > | ------ | > | 0 | > | 1 | > | 2 | > | 3 | > | 4 | > | 5 | > | 6 | > | 7 | > | 8 | > | 9 | > | 10 | > | 11 | > | 12 | > | 13 | > | 14 | > | 15 | > | 16 | > | 17 | > | 18 | > | 19 | > | 20 | > | 21 | > | 22 | > | 23 | > | 24 | > | 25 | > | 26 | > | 27 | > | 28 | > | 29 | > | 30 | > | 31 | > | 32 | > | 33 | > | 34 | > | 35 | > | 36 | > | 37 | > | 38 | > | 39 | > | 40 | > | 41 | > | 42 | > | 43 | > | 44 | > | 45 | > | 46 | > | 47 | > | 48 | > | 49 | > ---------- -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5339) Vertica join query fails due to unexpected ordering of intermediate results

by Jan Stastny (JIRA)

Jan Stastny created TEIID-5339: ---------------------------------- Summary: Vertica join query fails due to unexpected ordering of intermediate results Key: TEIID-5339 URL: https://issues.jboss.org/browse/TEIID-5339 Project: Teiid Issue Type: Bug Components: Misc. Connectors Affects Versions: 8.12.13.6_4 Reporter: Jan Stastny Assignee: Steven Hawkins Description of problem: There is unexpected error caused by TEIID-4129 fix. Error: TEIID31202 Detected that an already sorted set of values was not in the expected order (typically UTF-16 / UCS-2). Please check the translator settings to ensure character columns used for joining are sorted as expected. Query: {code:sql} SELECT BQT1.SmallA.IntKey, BQT2.SmallB.DoubleNum FROM BQT1.SmallA, BQT2.SmallB WHERE BQT1.SmallA.IntKey = BQT2.SmallB.DoubleNum {code} The property 'org.teiid.assumeMatchingCollation' is not set, thus default value is false. Teiid should resolve the issue with different ordering. Pushed source commands: 1. {code:sql} SELECT g_0."doublenum" AS c_0 FROM "dvqe"."public"."smallb" AS g_0 ORDER BY c_0 {code} 2. {code:sql} SELECT g_0."intkey" FROM "dvqe"."public"."smalla" AS g_0 {code} When I run the query 1 against actual vertica instance I get result as: ---------- | c_0 | | ------ | | -24.0 | | -23.0 | | -22.0 | | -21.0 | | -19.0 | | -18.0 | | -17.0 | | -16.0 | | -15.0 | | -14.0 | | -13.0 | | -12.0 | | -11.0 | | -10.0 | | -9.0 | | -8.0 | | -7.0 | | -6.0 | | -5.0 | | -3.0 | | -2.0 | | -1.0 | | 0.0 | | 1.0 | | 2.0 | | 3.0 | | 4.0 | | 5.0 | | 6.0 | | 7.0 | | 8.0 | | 9.0 | | 10.0 | | 11.0 | | 13.0 | | 14.0 | | 15.0 | | 16.0 | | 17.0 | | 18.0 | | 19.0 | | 20.0 | | 21.0 | | 22.0 | | 23.0 | | 24.0 | | 25.0 | | <null> | | <null> | | <null> | ---------- Driver states the type is Float. Query 2: ---------- | intkey | | ------ | | 0 | | 1 | | 2 | | 3 | | 4 | | 5 | | 6 | | 7 | | 8 | | 9 | | 10 | | 11 | | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20 | | 21 | | 22 | | 23 | | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | | 30 | | 31 | | 32 | | 33 | | 34 | | 35 | | 36 | | 37 | | 38 | | 39 | | 40 | | 41 | | 42 | | 43 | | 44 | | 45 | | 46 | | 47 | | 48 | | 49 | ---------- -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3733) Add support for web scraping

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3733?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-3733: ---------------------------------- Fix Version/s: 10.x > Add support for web scraping > ---------------------------- > > Key: TEIID-3733 > URL: https://issues.jboss.org/browse/TEIID-3733 > Project: Teiid > Issue Type: Feature Request > Components: Misc. Connectors > Reporter: Van Halbert > Fix For: 10.x, 10.3 > > > Add support for web scraping. > Here's one from CA using JSoup - https://github.com/rokhmanov/teiid-translators/blob/master/translator-scr... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues May 2018