March 2017 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-4828) ST_GeomFromGeoJson fails for certain geometry types

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4828?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-4828: ---------------------------------- Fix Version/s: 9.3 > ST_GeomFromGeoJson fails for certain geometry types > --------------------------------------------------- > > Key: TEIID-4828 > URL: https://issues.jboss.org/browse/TEIID-4828 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 9.3, 8.12.10.6_3 > Reporter: Andrej Šmigala > Assignee: Steven Hawkins > Fix For: 9.3 > > > ST_GeomFromGeoJson fails to decode GeoJSON with certain geometry types. The following queries work: > {code:sql|title=Working Queries} > select ST_GeomFromGeoJson(ST_AsGeoJSON(ST_GeomFromText('POINT (30 10)'))) > select ST_GeomFromGeoJson(ST_AsGeoJSON(ST_GeomFromText('POLYGON ((30 10, 40 40, 20 40, 10 20, 30 10))'))); > select ST_GeomFromGeoJson(ST_AsGeoJSON(ST_GeomFromText('POLYGON ((35 10, 45 45, 15 40, 10 20, 35 10),(20 30, 35 35, 30 20, 20 30))'))); > select ST_GeomFromGeoJson(ST_AsGeoJSON(ST_GeomFromText('MULTIPOLYGON (((30 20, 45 40, 10 40, 30 20)),((15 5, 40 10, 10 20, 5 10, 15 5)))'))); > select ST_GeomFromGeoJson(ST_AsGeoJSON(ST_GeomFromText('MULTIPOLYGON (((40 40, 20 45, 45 30, 40 40)),((20 35, 10 30, 10 10, 30 5, 45 20, 20 35),(30 20, 20 15, 20 25, 30 20)))'))); > {code} > but these fail: > {code:sql|title=Failing Queries} > select ST_GeomFromGeoJson(ST_AsGeoJSON(ST_GeomFromText('MULTIPOINT ((10 40), (40 30), (20 20), (30 10))'))); > select ST_GeomFromGeoJson(ST_AsGeoJSON(ST_GeomFromText('MULTIPOINT (10 40, 40 30, 20 20, 30 10)'))); > select ST_GeomFromGeoJson(ST_AsGeoJSON(ST_GeomFromText('MULTILINESTRING ((10 10, 20 20, 10 40),(40 40, 30 30, 40 20, 30 10))'))); > select ST_GeomFromGeoJson(ST_AsGeoJSON(ST_GeomFromText('LINESTRING (30 10, 10 30, 40 40)'))); > {code} > The server log when running with master says > {noformat} > TEIID30328 Unable to evaluate ST_GeomFromGeoJson(?): TEIID30384 Error while evaluating function st_geomfromgeojson'. Originally ExpressionEvaluationException 'Conflicting property-based creators: already had explicitly marked [constructor for org.wololo.geojson.MultiPoint, annotations: {interface com.fasterxml.jackson.annotation.JsonCreator=(a)com.fasterxml.jackson.annotation.JsonCreator(mode=DEFAULT)}], encountered [constructor for org.wololo.geojson.MultiPoint, annotations: {interface com.fasterxml.jackson.annotation.JsonCreator=(a)com.fasterxml.jackson.annotation.JsonCreator(mode=DEFAULT)}]' CreatorCollector.java:304. > {noformat} > When running with latest 6.3 patch, the server log says > {noformat} > TEIID30328 Unable to evaluate ST_GeomFromGeoJson(?): TEIID30384 Error while evaluating function st_geomfromgeojson'. Originally ExpressionEvaluationException '1' BasicDeserializerFactory.java:394. > {noformat} > The difference seems to be due to different versions of jackson-databind (which also seems to be the source of the problem). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4827) Update the readme to indicate that Java 1.8 is required for building

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4827?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-4827: --------------------------------------- Just moving the source to 1.8 results in a build failure for the admin module. So we could look to resolve that and any other similar issues, or just require JDK 1.8. > Update the readme to indicate that Java 1.8 is required for building > -------------------------------------------------------------------- > > Key: TEIID-4827 > URL: https://issues.jboss.org/browse/TEIID-4827 > Project: Teiid > Issue Type: Bug > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.3 > > > There are several places where we are implicitly depending upon 1.8 features to build - such as the larger key size from TestDhKeyGenerator. These issues do not affect compatibility with a 1.7 runtime. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4827) Update the readme to indicate that Java 1.8 is required for building

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-4827?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-4827: ------------------------------------- I thought the ask is move the compile target to 1.8. What does setting "jdk.min.version" do? just forces one to compile with 1.8? Why not move 1.8 compile, and keep runtime to 1.7 > Update the readme to indicate that Java 1.8 is required for building > -------------------------------------------------------------------- > > Key: TEIID-4827 > URL: https://issues.jboss.org/browse/TEIID-4827 > Project: Teiid > Issue Type: Bug > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.3 > > > There are several places where we are implicitly depending upon 1.8 features to build - such as the larger key size from TestDhKeyGenerator. These issues do not affect compatibility with a 1.7 runtime. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4661) Subsequent queries hang after materialized view TTL expires.

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4661?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-4661: --------------------------------------- > With internal materialization, there is no ttl-driven load running in background, is there? If materialization management is enabled, then yes there will be - in this case you don't have that enabled. > So it is safe to wait longer than ttl for it to expire and expect that next load is triggered only when the view is queried, isn't it? With lazy-invalidate there isn't a hard guarantee on the timing. On a heavily loaded box it may not complete when expected. > Is my testing approach incorrect? The primary concerns here are that the materialization is getting refreshed and that subsequent queries aren't hanging. If we are transitioning back out of the loading state and this is just a timing issue, then it's not a concern. > Subsequent queries hang after materialized view TTL expires. > ------------------------------------------------------------ > > Key: TEIID-4661 > URL: https://issues.jboss.org/browse/TEIID-4661 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.12.x > Reporter: Colin Mondesir > Assignee: Steven Hawkins > Priority: Critical > Fix For: 9.0.6, 9.1.2, 9.2, 8.12.10.6_3 > > > With a VDB using lazy-invalidate in a clustered configuration initially the materialized view is cached correctly but when the TTL expires (10 minutes) and the query is run again the state of the view changes to LOADING and never reverts to "LOADED", so the next query hangs. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4828) ST_GeomFromGeoJson fails for certain geometry types

by Andrej Šmigala (JIRA)

Andrej Šmigala created TEIID-4828: ------------------------------------- Summary: ST_GeomFromGeoJson fails for certain geometry types Key: TEIID-4828 URL: https://issues.jboss.org/browse/TEIID-4828 Project: Teiid Issue Type: Bug Components: Query Engine Affects Versions: 9.3, 8.12.10.6_3 Reporter: Andrej Šmigala Assignee: Steven Hawkins ST_GeomFromGeoJson fails to decode GeoJSON with certain geometry types. The following queries work: {code:sql|title=Working Queries} select ST_GeomFromGeoJson(ST_AsGeoJSON(ST_GeomFromText('POINT (30 10)'))) select ST_GeomFromGeoJson(ST_AsGeoJSON(ST_GeomFromText('POLYGON ((30 10, 40 40, 20 40, 10 20, 30 10))'))); select ST_GeomFromGeoJson(ST_AsGeoJSON(ST_GeomFromText('POLYGON ((35 10, 45 45, 15 40, 10 20, 35 10),(20 30, 35 35, 30 20, 20 30))'))); select ST_GeomFromGeoJson(ST_AsGeoJSON(ST_GeomFromText('MULTIPOLYGON (((30 20, 45 40, 10 40, 30 20)),((15 5, 40 10, 10 20, 5 10, 15 5)))'))); select ST_GeomFromGeoJson(ST_AsGeoJSON(ST_GeomFromText('MULTIPOLYGON (((40 40, 20 45, 45 30, 40 40)),((20 35, 10 30, 10 10, 30 5, 45 20, 20 35),(30 20, 20 15, 20 25, 30 20)))'))); {code} but these fail: {code:sql|title=Failing Queries} select ST_GeomFromGeoJson(ST_AsGeoJSON(ST_GeomFromText('MULTIPOINT ((10 40), (40 30), (20 20), (30 10))'))); select ST_GeomFromGeoJson(ST_AsGeoJSON(ST_GeomFromText('MULTIPOINT (10 40, 40 30, 20 20, 30 10)'))); select ST_GeomFromGeoJson(ST_AsGeoJSON(ST_GeomFromText('MULTILINESTRING ((10 10, 20 20, 10 40),(40 40, 30 30, 40 20, 30 10))'))); select ST_GeomFromGeoJson(ST_AsGeoJSON(ST_GeomFromText('LINESTRING (30 10, 10 30, 40 40)'))); {code} The server log when running with master says {noformat} TEIID30328 Unable to evaluate ST_GeomFromGeoJson(?): TEIID30384 Error while evaluating function st_geomfromgeojson'. Originally ExpressionEvaluationException 'Conflicting property-based creators: already had explicitly marked [constructor for org.wololo.geojson.MultiPoint, annotations: {interface com.fasterxml.jackson.annotation.JsonCreator=(a)com.fasterxml.jackson.annotation.JsonCreator(mode=DEFAULT)}], encountered [constructor for org.wololo.geojson.MultiPoint, annotations: {interface com.fasterxml.jackson.annotation.JsonCreator=(a)com.fasterxml.jackson.annotation.JsonCreator(mode=DEFAULT)}]' CreatorCollector.java:304. {noformat} When running with latest 6.3 patch, the server log says {noformat} TEIID30328 Unable to evaluate ST_GeomFromGeoJson(?): TEIID30384 Error while evaluating function st_geomfromgeojson'. Originally ExpressionEvaluationException '1' BasicDeserializerFactory.java:394. {noformat} The difference seems to be due to different versions of jackson-databind (which also seems to be the source of the problem). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4661) Subsequent queries hang after materialized view TTL expires.

by Jan Stastny (JIRA)

[ https://issues.jboss.org/browse/TEIID-4661?page=com.atlassian.jira.plugin... ] Jan Stastny commented on TEIID-4661: ------------------------------------ I am using this vdb for testing: {code:xml|title=teiid4661-vdb.xml} <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <vdb name="teiid4661" version="1"> <property name="lazy-invalidate" value="true" /> <model name="loopback" type="PHYSICAL"> <property name="importer.importKeys" value="true" /> <property name="importer.importProcedures" value="true" /> <source name="loopback-source" translator-name="loopback-override" /> <metadata type="NATIVE,DDL"><![CDATA[ CREATE FOREIGN TABLE customers ( id integer PRIMARY KEY, name varchar(255), salary long); CREATE FOREIGN TABLE orders ( id integer PRIMARY KEY, name varchar(255)); ]]> </metadata> </model> <model name="View" type="VIRTUAL"> <metadata type="DDL"><![CDATA[ CREATE VIEW Data ( id integer, name string, id_1 integer, name_1 string, salary long ) options (materialized true) AS /*+ cache(ttl:1000) */ select c.id as id, c.name as name, o.id as id_1, o.name as name_1, c.salary as salary from customers c, orders o ; ]]> </metadata> </model> <translator name="loopback-override" type="loopback"> <property name="DelegateName" value="jdbc-simple" /> <property name="RowCount" value="50" /> <property name="IncrementRows" value="true" /> </translator> </vdb> {code} Is my testing approach incorrect? With internal materialization, there is no ttl-driven load running in background, is there? So it is safe to wait longer than ttl for it to expire and expect that next load is triggered only when the view is queried, isn't it? > Subsequent queries hang after materialized view TTL expires. > ------------------------------------------------------------ > > Key: TEIID-4661 > URL: https://issues.jboss.org/browse/TEIID-4661 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.12.x > Reporter: Colin Mondesir > Assignee: Steven Hawkins > Priority: Critical > Fix For: 9.0.6, 9.1.2, 9.2, 8.12.10.6_3 > > > With a VDB using lazy-invalidate in a clustered configuration initially the materialized view is cached correctly but when the TTL expires (10 minutes) and the query is run again the state of the view changes to LOADING and never reverts to "LOADED", so the next query hangs. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4827) Update the readme to indicate that Java 1.8 is required for building

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4827?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-4827: --------------------------------------- I can update the jdk.min.version property to 1.8, but the compile source/target will need to remain 1.7. Is that what you are looking for? > Update the readme to indicate that Java 1.8 is required for building > -------------------------------------------------------------------- > > Key: TEIID-4827 > URL: https://issues.jboss.org/browse/TEIID-4827 > Project: Teiid > Issue Type: Bug > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.3 > > > There are several places where we are implicitly depending upon 1.8 features to build - such as the larger key size from TestDhKeyGenerator. These issues do not affect compatibility with a 1.7 runtime. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4825) Google translator throws Column doesn't exist in the worksheet

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4825?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-4825: ---------------------------------- Fix Version/s: 9.3 > Google translator throws Column doesn't exist in the worksheet > -------------------------------------------------------------- > > Key: TEIID-4825 > URL: https://issues.jboss.org/browse/TEIID-4825 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 8.12.10.6_3 > Reporter: Lucie Fabrikova > Assignee: Steven Hawkins > Fix For: 9.3 > > Attachments: gs-export-vdb.xml, server.log-dv635cr1 > > > If sheet (WikiData9) contains only string type columns, queries to that sheet fail with 'org.teiid.resource.adapter.google.common.SpreadsheetOperationException: Column link doesn't exist in the worksheet WikiData9' > If I added e.g. numeric or boolean column, it worked ok... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4827) Update the readme to indicate that Java 1.8 is required for building

by Damien B (JIRA)

[ https://issues.jboss.org/browse/TEIID-4827?page=com.atlassian.jira.plugin... ] Damien B commented on TEIID-4827: --------------------------------- I think the POM should be updated as well to enforce those rules (1.8 for library compatibility, 1.7 for runtime): with a fresh environment on Eclipse with m2e, the 1.7 rule is enforced on the library compatibility and the project appears broken (missing method in some JDK class and no support on default method elsewhere). > Update the readme to indicate that Java 1.8 is required for building > -------------------------------------------------------------------- > > Key: TEIID-4827 > URL: https://issues.jboss.org/browse/TEIID-4827 > Project: Teiid > Issue Type: Bug > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.3 > > > There are several places where we are implicitly depending upon 1.8 features to build - such as the larger key size from TestDhKeyGenerator. These issues do not affect compatibility with a 1.7 runtime. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4827) Update the readme to indicate that Java 1.8 is required for building

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4827?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-4827. ----------------------------------- Resolution: Done Updated the readme > Update the readme to indicate that Java 1.8 is required for building > -------------------------------------------------------------------- > > Key: TEIID-4827 > URL: https://issues.jboss.org/browse/TEIID-4827 > Project: Teiid > Issue Type: Bug > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.3 > > > There are several places where we are implicitly depending upon 1.8 features to build - such as the larger key size from TestDhKeyGenerator. These issues do not affect compatibility with a 1.7 runtime. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues March 2017