September 2015 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-3693) Add data source support for reading documents (i.e., RTF, DOC, PDF)

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3693?page=com.atlassian.jira.plugin... ] Steven Hawkins reassigned TEIID-3693: ------------------------------------- Assignee: Van Halbert (was: Steven Hawkins) Assigning over to Van to flesh out the requirements. > Add data source support for reading documents (i.e., RTF, DOC, PDF) > ------------------------------------------------------------------- > > Key: TEIID-3693 > URL: https://issues.jboss.org/browse/TEIID-3693 > Project: Teiid > Issue Type: Feature Request > Components: Misc. Connectors > Reporter: Van Halbert > Assignee: Van Halbert > > Add data source support for reading documents (i.e., RTF, DOC, PDF). > From a runtime perspective the extraction logic is straight-forward when there is a parsing library. Here's one from CA using JSoup - https://github.com/rokhmanov/teiid-translators/blob/master/translator-scr... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2729) Dynamic VDB xml requires sibling elements to be in a certain order

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2729?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2729: --------------------------------------- Warnings don't really make sense unless we are going to enforce the existing schema again at some point. If we remain flexible or relax the schema, then the warnings would just be clutter. Also how strict do we want to be? Should we also reject incorrect attributes? > Dynamic VDB xml requires sibling elements to be in a certain order > ------------------------------------------------------------------ > > Key: TEIID-2729 > URL: https://issues.jboss.org/browse/TEIID-2729 > Project: Teiid > Issue Type: Enhancement > Components: AdminApi > Affects Versions: 8.5 > Reporter: Mark Drilling > Assignee: Steven Hawkins > Fix For: 8.7 > > > In my *-vdb.xml, I have a model defined per following snippet: > <model name="myModel" type="PHYSICAL" visible="true"> > <source name="myModel" translator-name="hive" connection-jndi-name="Hive12Src" /> > <property name="trimColumnNames" value="true" /> > </model> > The vdb.xml failed to parse, so I moved the <property> element ahead of <source> and then it worked. > I don't think element ordering should matter in this case? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3564) float field gets converted to scientific notation when query is submitted to source

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3564?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-3564. ----------------------------------- Fix Version/s: 8.12 8.11.5 Resolution: Done Updated the salesforce logic and adding handling for BigDecimal in JDBC as well. > float field gets converted to scientific notation when query is submitted to source > ----------------------------------------------------------------------------------- > > Key: TEIID-3564 > URL: https://issues.jboss.org/browse/TEIID-3564 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.7.1 > Environment: RHEL 6, AWS Virtual Machine, salesforce.com soap api 23.0,JBoss EAP (standalone) 6.3.2.GA > JBoss Data Virtualization 6.1.0.ER4 > Reporter: Jorge Herrera > Assignee: Steven Hawkins > Fix For: 8.12, 8.11.5 > > > When submitting the following query: > SELECT COUNT(*) FROM salesforce_sales.salesforce.Opportunity where amount > 100000000; > to a salesforce instance with the shown filter it returns the following error: > org.teiid.runtime.client.TeiidClientException: java.lang.RuntimeException: Remote org.teiid.core.TeiidProcessingException: TEIID30504 SalesForce_Sales: com.sforce.soap.partner.MalformedQueryFault: MALFORMED_QUERY: > Opportunity WHERE Opportunity.Amount > 1.0E8 > ^ > ERROR at Row:1:Column:64 > unexpected token: 'E8' > Elapsed Time: 0 hr, 0 min, 1 sec, 109 ms. > why is the quantity modified when the field is declared as float? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3564) float field gets converted to scientific notation when query is submitted to source

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3564?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-3564: ---------------------------------- Security: (was: Red Hat Internal) > float field gets converted to scientific notation when query is submitted to source > ----------------------------------------------------------------------------------- > > Key: TEIID-3564 > URL: https://issues.jboss.org/browse/TEIID-3564 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.7.1 > Environment: RHEL 6, AWS Virtual Machine, salesforce.com soap api 23.0,JBoss EAP (standalone) 6.3.2.GA > JBoss Data Virtualization 6.1.0.ER4 > Reporter: Jorge Herrera > Assignee: Steven Hawkins > > When submitting the following query: > SELECT COUNT(*) FROM salesforce_sales.salesforce.Opportunity where amount > 100000000; > to a salesforce instance with the shown filter it returns the following error: > org.teiid.runtime.client.TeiidClientException: java.lang.RuntimeException: Remote org.teiid.core.TeiidProcessingException: TEIID30504 SalesForce_Sales: com.sforce.soap.partner.MalformedQueryFault: MALFORMED_QUERY: > Opportunity WHERE Opportunity.Amount > 1.0E8 > ^ > ERROR at Row:1:Column:64 > unexpected token: 'E8' > Elapsed Time: 0 hr, 0 min, 1 sec, 109 ms. > why is the quantity modified when the field is declared as float? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3638) Analytical Functions Push-down Optimization

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3638?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3638: --------------------------------------- Analytical functions are just like any other query construct to us. If the optimizer can push them down, then they will be pushed. Otherwise they will be executed in the engine. https://docs.jboss.org/author/display/TEIID/Expressions has a section on supported window functions, and the full grammar is in https://docs.jboss.org/author/display/TEIID/BNF+for+SQL+Grammar Can you clarify what enhancements/documentation you are looking for? > Analytical Functions Push-down Optimization > ------------------------------------------- > > Key: TEIID-3638 > URL: https://issues.jboss.org/browse/TEIID-3638 > Project: Teiid > Issue Type: Enhancement > Components: Query Engine > Affects Versions: 8.7.1 > Environment: RHEL 6, AWS VM, JBoss EAP (standalone) 6.3.2.GA > JBoss Data Virtualization 6.1.0.ER4 > Reporter: Jorge Herrera > Assignee: Steven Hawkins > > Enhancements and/or more documentation as to how Analytical functions work from JDV perspective. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2973) OData 4 support with Olingo

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-2973?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-2973: ------------------------------------- >From above list 5, 11, 13 now should be supported. I have written the XML serialization for Olingo framework to be included in 4.0. > OData 4 support with Olingo > --------------------------- > > Key: TEIID-2973 > URL: https://issues.jboss.org/browse/TEIID-2973 > Project: Teiid > Issue Type: Task > Components: Misc. Connectors, OData > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Labels: CR1 > Fix For: 8.11 > > > Whenever an olingo final is available for odata 3/4 we'll want to utilize that. The best guess now is that this will happen in the 8.9 timeframe. Additional support can then be added for later odata features, which will have subtasks as necessary. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2973) OData 4 support with Olingo

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-2973?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-2973: ------------------------------------- [~vasudevan_madubhushi] Olingo 4.0 released yesterday, and I could finally merge changes related to the expand with following merge https://github.com/teiid/teiid/commit/ea80b44e02d33505c13d140c13f77d75b6f... This will be in 8.12 CR1 which will be released next week. Any help with testing OData v4 is greatly appreciated. > OData 4 support with Olingo > --------------------------- > > Key: TEIID-2973 > URL: https://issues.jboss.org/browse/TEIID-2973 > Project: Teiid > Issue Type: Task > Components: Misc. Connectors, OData > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Labels: CR1 > Fix For: 8.11 > > > Whenever an olingo final is available for odata 3/4 we'll want to utilize that. The best guess now is that this will happen in the 8.9 timeframe. Additional support can then be added for later odata features, which will have subtasks as necessary. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2729) Dynamic VDB xml requires sibling elements to be in a certain order

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-2729?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-2729: ------------------------------------- Validate but may be post as warnings, and let the deployment fail if vdb xml is in fact wrong? > Dynamic VDB xml requires sibling elements to be in a certain order > ------------------------------------------------------------------ > > Key: TEIID-2729 > URL: https://issues.jboss.org/browse/TEIID-2729 > Project: Teiid > Issue Type: Enhancement > Components: AdminApi > Affects Versions: 8.5 > Reporter: Mark Drilling > Assignee: Steven Hawkins > Fix For: 8.7 > > > In my *-vdb.xml, I have a model defined per following snippet: > <model name="myModel" type="PHYSICAL" visible="true"> > <source name="myModel" translator-name="hive" connection-jndi-name="Hive12Src" /> > <property name="trimColumnNames" value="true" /> > </model> > The vdb.xml failed to parse, so I moved the <property> element ahead of <source> and then it worked. > I don't think element ordering should matter in this case? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2729) Dynamic VDB xml requires sibling elements to be in a certain order

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2729?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2729: --------------------------------------- Filip was asking about this as well. One possibility is that we simply not validate during deployment and simply have the xsd as a tooling reference. > Dynamic VDB xml requires sibling elements to be in a certain order > ------------------------------------------------------------------ > > Key: TEIID-2729 > URL: https://issues.jboss.org/browse/TEIID-2729 > Project: Teiid > Issue Type: Enhancement > Components: AdminApi > Affects Versions: 8.5 > Reporter: Mark Drilling > Assignee: Steven Hawkins > Fix For: 8.7 > > > In my *-vdb.xml, I have a model defined per following snippet: > <model name="myModel" type="PHYSICAL" visible="true"> > <source name="myModel" translator-name="hive" connection-jndi-name="Hive12Src" /> > <property name="trimColumnNames" value="true" /> > </model> > The vdb.xml failed to parse, so I moved the <property> element ahead of <source> and then it worked. > I don't think element ordering should matter in this case? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3707) Wrong Data returned when a procedure is executed in the SELECT clause

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3707?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3707: --------------------------------------- Can you confirm if this behaves differently with the commit https://github.com/teiid/teiid/commit/b3bdab3299fc6174bb38b2f1e5d508a463f... What I see running this test on latest in a tight loop is that threads, cpu, and memory usage, are all stable. That's with oracle 1.8 or openjdk 1.7/1.8. > Wrong Data returned when a procedure is executed in the SELECT clause > --------------------------------------------------------------------- > > Key: TEIID-3707 > URL: https://issues.jboss.org/browse/TEIID-3707 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 7.6 > Reporter: dalex dalex > Assignee: Steven Hawkins > Priority: Blocker > Fix For: 8.12, 8.11.5, 8.7.5 > > Attachments: highcpu-threads.png, out.1, out.2, out.3, sample_coords.sql, wrong_data.jpg > > > I've found the following problem when executing a stored procedure in the SELECT clause. It calculates wrong data in a seemingly random fashion. > This is a stored procedure which was created to determine whether a given coordinate lies within a specific rectangle. If this procedure is tested in a simple manner (SELECT .. FROM (EXEC ..)) the results are correctly retuned (0 = outside the rectangle and 1 otherwise). > {code:sql} > CREATE virtual procedure point_inside_store ( > pos_x float > ,pos_y float > ) RETURNS ( > "insideFence" integer > ) AS > BEGIN > DECLARE integer insideFence = 0 ; > DECLARE float lowerLimit = 0.0 ; > DECLARE float upperLimit = 17.0 ; > DECLARE float leftLimit = 0.0 ; > DECLARE float rightLimit = 53.0 ; > IF ( > pos_x >= leftLimit > AND pos_x <= rightLimit > AND pos_y >= lowerLimit > AND pos_y <= upperLimit > ) > BEGIN > insideFence = 1 ; > END > SELECT > insideFence ; > END > {code} > If now the same procedure is included in a SELECT clause of a query: > {code:sql} > SELECT > "citmp.KoordX" > ,"citmp.KoordY" > ,( > SELECT > "store.insideFence" > FROM > ( > EXEC procs.point_inside_store ( > CAST ( > "citmp.KoordX" AS float > ) > ,CAST ( > "citmp.KoordY" AS float > ) > ) > ) as "store" > ) as "insideStore" > ,( > SELECT > "firstsection.insideFence" > FROM > ( > EXEC procs.point_inside_store ( > CAST ( > "citmp.KoordX" AS float > ) > ,CAST ( > "citmp.KoordY" AS float > ) > ) > ) as "firstsection" > ) as "insideFirstsection" > FROM > "test.sample_coords" as "citmp" > ORDER BY > insideStore ASC > ,insideFirstsection DESC;; > {code} > it calculates different results. The same coordinates that yielded 0 before now yield 1. > !wrong_data.jpg|thumbnail! > Note that the main query has 2 columns executing the exact same procedure but there are result sets, that have different values in the last two columns. This should not be possible. > In attachment you will find sample_coords table with a sample of coordinates. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues September 2015