February 2014 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-2843) MongoDB: ClassCastException while doing JOIN based query

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-2843?page=com.atlassian.jira.plugin... ] Ramesh Reddy resolved TEIID-2843. --------------------------------- Labels: Alpha3 mongodb (was: mongodb) Resolution: Done This was simply a coding error. I previously assumed that in muti-table JOIN scenario command always opens up LEFT side a JOIN and right as leaf. Corrected to handle both ways. > MongoDB: ClassCastException while doing JOIN based query > -------------------------------------------------------- > > Key: TEIID-2843 > URL: https://issues.jboss.org/browse/TEIID-2843 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 8.4 > Reporter: Ramesh Reddy > Assignee: Ramesh Reddy > Labels: mongodb, Alpha3 > Fix For: 8.7 > > > With Schema like > {code} > CREATE FOREIGN TABLE Company ( > name varchar(50) PRIMARY KEY, > description varchar(256) > ) OPTIONS(UPDATABLE 'TRUE',"teiid_mongo:EMBEDDABLE" 'true'); > CREATE FOREIGN TABLE Job ( > jobId integer PRIMARY KEY, > description varchar(256), > companyname varchar(50), > FOREIGN KEY (companyname) REFERENCES Company (name) > ) OPTIONS(UPDATABLE 'TRUE', "teiid_mongo:EMBEDDABLE" 'true'); > > CREATE FOREIGN TABLE Employee ( > ename varchar(50) PRIMARY KEY, > jobId integer, > FOREIGN KEY (jobId) REFERENCES Job (jobId) > ) OPTIONS(UPDATABLE 'TRUE'); > {code} > then doing a single JOIN Query > {code} > select e.ename, c.name, j.description from Employee as e JOIN Job j ON e.jobId = j.jobId JOIN Company c ON j.companyname = c.name > {code} > fails with > {code} > 14:22:05,271 ERROR [org.teiid.PROCESSOR] (Worker23_QueryProcessorQueue432) 258Se2CWMytI TEIID30019 Unexpected exception for request 258Se2CWMytI.28: java.lang.ClassCastException: org.teiid.language.Join cannot be cast to org.teiid.language.NamedTable > at org.teiid.translator.mongodb.MongoDBSelectVisitor.visit(MongoDBSelectVisitor.java:419) > at org.teiid.language.Join.acceptVisitor(Join.java:66) [teiid-api-8.7.0.Alpha3-SNAPSHOT.jar:8.7.0.Alpha3-SNAPSHOT] > at org.teiid.language.visitor.AbstractLanguageVisitor.visitNode(AbstractLanguageVisitor.java:51) [teiid-api-8.7.0.Alpha3-SNAPSHOT.jar:8.7.0.Alpha3-SNAPSHOT] > at org.teiid.translator.mongodb.MongoDBSelectVisitor.append(MongoDBSelectVisitor.java:95) > at org.teiid.translator.mongodb.MongoDBSelectVisitor.append(MongoDBSelectVisitor.java:106) > at org.teiid.translator.mongodb.MongoDBSelectVisitor.visit(MongoDBSelectVisitor.java:482) > at org.teiid.language.Select.acceptVisitor(Select.java:103) [teiid-api-8.7.0.Alpha3-SNAPSHOT.jar:8.7.0.Alpha3-SNAPSHOT] > at org.teiid.language.visitor.AbstractLanguageVisitor.visitNode(AbstractLanguageVisitor.java:51) [teiid-api-8.7.0.Alpha3-SNAPSHOT.jar:8.7.0.Alpha3-SNAPSHOT] > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2845) MongoDB: Join processing produces wrong results in some cases

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-2845?page=com.atlassian.jira.plugin... ] Ramesh Reddy resolved TEIID-2845. --------------------------------- Labels: alpha3 mongodb (was: mongodb) Resolution: Done The $unwind operator behavior was wrongly assumed, where the empty child documents did not produce any documents, so all joins were behaving as INNER joins. See related discussion on it https://groups.google.com/forum/#!topic/mongodb-user/UKYPddRN37E Used the workaround mentioned on this thread, so that Teiid can generate * INNER JOIN * LEFT [OUTER] JOIN (left is assumed to be the parent document) * CROSS JOIN will be handled by the Teiid engine, as the JOIN capabilities define they only work on KEY based. * RIGHT OUTER JOIN either re-written based on which side is parent, otherwise this JOIN produces an exception. One possibility is to extend the "allow-join" semantics to define such that "RIGHT JOIN" is not supported, in which case it can be handled in Teiid query engine. > MongoDB: Join processing produces wrong results in some cases > ------------------------------------------------------------- > > Key: TEIID-2845 > URL: https://issues.jboss.org/browse/TEIID-2845 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 8.4 > Reporter: Ramesh Reddy > Assignee: Ramesh Reddy > Labels: mongodb, alpha3 > Fix For: 8.7 > > > When two or more tables are used to build single document in the MongoDB, depending upon the JOIN query used it may produce wrong results. > - support for inner is not turned ON, this should be allowed > - For example cross-join between parent and embedded table > - right-join between parent and embedded table > - depending upon the parent the ordering of left and right join -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2714) Buffer defrag not working

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-2714?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-2714: ------------------------------------------------ wgibson(a)redhat.com changed the Status of [bug 1028023|https://bugzilla.redhat.com/show_bug.cgi?id=1028023] from ON_QA to VERIFIED > Buffer defrag not working > ------------------------- > > Key: TEIID-2714 > URL: https://issues.jboss.org/browse/TEIID-2714 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 7.7 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.6, 7.7.9 > > > The defrag task is not working as expected because the header values are written by an object output stream - and not as standalone values into the block data. > For most data usage patterns this isn't an issue as the storage files are self compacting over time due to low block assignments. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2747) Wrong results with merge join SORT_DISTINCT with a full sort that is distinct beyond the join columns

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-2747?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-2747: ------------------------------------------------ wgibson(a)redhat.com changed the Status of [bug 1033056|https://bugzilla.redhat.com/show_bug.cgi?id=1033056] from ON_QA to VERIFIED > Wrong results with merge join SORT_DISTINCT with a full sort that is distinct beyond the join columns > ----------------------------------------------------------------------------------------------------- > > Key: TEIID-2747 > URL: https://issues.jboss.org/browse/TEIID-2747 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 7.4 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Blocker > Fix For: 8.4.1, 8.6 > > > To speed up processing of a sort merge join we attempt to eliminate extra comparisons by detecting if the equi-join column values are distinct. In plans where the sorted values are distinct beyond the equi-join values such that the equi-join column values are non-distinct, then incorrect results can be returned. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2707) proactive buffering on an enhanced sort merge left outer join results in an assertionerror

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-2707?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-2707: ------------------------------------------------ wgibson(a)redhat.com changed the Status of [bug 1028027|https://bugzilla.redhat.com/show_bug.cgi?id=1028027] from ON_QA to VERIFIED > proactive buffering on an enhanced sort merge left outer join results in an assertionerror > ------------------------------------------------------------------------------------------ > > Key: TEIID-2707 > URL: https://issues.jboss.org/browse/TEIID-2707 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.4 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.4.1, 8.6, 7.7.9 > > > The proactive buffering logic with particular blocking patterns is not correct. Namely the setting of the buffer to forward only prevents re-reading which results in an AssertionError. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2733) TEIID-2633 goes too far

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-2733?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-2733: ------------------------------------------------ wgibson(a)redhat.com changed the Status of [bug 1029914|https://bugzilla.redhat.com/show_bug.cgi?id=1029914] from ON_QA to VERIFIED > TEIID-2633 goes too far > ----------------------- > > Key: TEIID-2733 > URL: https://issues.jboss.org/browse/TEIID-2733 > Project: Teiid > Issue Type: Quality Risk > Components: Query Engine > Affects Versions: 8.4.1, 8.5, 7.7.8 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.4.1, 8.6 > > > TEIID-2633 can have a negative performance impact if discovered transitive criteria is removed that could help filter more rows from a multi-column dependent join. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2728) Very large sorts are inefficient

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-2728?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-2728: ------------------------------------------------ wgibson(a)redhat.com changed the Status of [bug 1028016|https://bugzilla.redhat.com/show_bug.cgi?id=1028016] from ON_QA to VERIFIED > Very large sorts are inefficient > -------------------------------- > > Key: TEIID-2728 > URL: https://issues.jboss.org/browse/TEIID-2728 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.4 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.4.1, 8.6 > > > This is a regression of TEIID-2429. When the memory space needed for a sort is estimated to be above 2 GB, the expression used (even though it's assigned to a long) will overflow. This then causes the processing to use the batch size as the intermediate sort buffer size, which for any high row count will lead to many passes (the logic typically should achieve at most a two pass sort). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2690) Tuples lost in a with clause item.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-2690?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-2690: ------------------------------------------------ wgibson(a)redhat.com changed the Status of [bug 1016243|https://bugzilla.redhat.com/show_bug.cgi?id=1016243] from ON_QA to VERIFIED > Tuples lost in a with clause item. > ---------------------------------- > > Key: TEIID-2690 > URL: https://issues.jboss.org/browse/TEIID-2690 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.1, 7.7.7 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Blocker > Fix For: 8.4.1, 8.6, 7.7.8 > > > Related to TEIID-2442 - the BatchIterator created for the creation of the temp table backing a with clause item cannot be created after blocking without loosing tuples. > On 8.3.x+ a single block is not sufficient to induce this behavior if there are any tuples that have been retrieved since the last block as the access node logic will return the partial batch. Thus may occur as a somewhat rare timing issue in 8.3.x+. However in 7.7.7/7.7.8 a single block cause the recreation of the BatchIterator making the affect almost certain once the row count exceeds the computed working batch size (nominally 256 rows, but allowed to vary based upon the row width). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2361) The current MAX String size is 4000, add the ability to configure when larger sizes are used

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-2361?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-2361: ------------------------------------------------ Filip Nguyen <fnguyen(a)redhat.com> changed the Status of [bug 896305|https://bugzilla.redhat.com/show_bug.cgi?id=896305] from ON_QA to VERIFIED > The current MAX String size is 4000, add the ability to configure when larger sizes are used > -------------------------------------------------------------------------------------------- > > Key: TEIID-2361 > URL: https://issues.jboss.org/browse/TEIID-2361 > Project: Teiid > Issue Type: Enhancement > Components: Query Engine > Reporter: Van Halbert > Assignee: Steven Hawkins > Fix For: 8.3, 7.7.7 > > > The MAX String size is currently 4000. After a discussion with Steve, he indicated a more common default might be 16k, and also add the ability to configure the size when a data source is being used that contains large sizes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2656) Teiid OData Servlet throws java.lang.NullPointerException on every GET

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-2656?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-2656: ------------------------------------------------ Filip Nguyen <fnguyen(a)redhat.com> changed the Status of [bug 1006961|https://bugzilla.redhat.com/show_bug.cgi?id=1006961] from ON_QA to VERIFIED > Teiid OData Servlet throws java.lang.NullPointerException on every GET > ---------------------------------------------------------------------- > > Key: TEIID-2656 > URL: https://issues.jboss.org/browse/TEIID-2656 > Project: Teiid > Issue Type: Bug > Affects Versions: 8.3, 8.4 > Environment: Windows 7 64 bit > Oracle JDK 1.7.0 update 17 > JBoss AS 7.1.1 + Teiid 8.3 (both resteasy-jaxrs 2.3.5 and 2.3.7) > JBoss EAP 6.1 + Teiid 8.4 (resteasy-jaxrs 2.3.6) > Reporter: John Muller > Assignee: Ramesh Reddy > Labels: final > Fix For: 8.5, 8.4.2 > > Attachments: server.log, Teiid_8.4_on_JBoss_EAP_6.1Alpha_RHEL6.log > > > A simple GET on any Teiid 8.3 or 8.4 OData ReST resource results in a Null Pointer: > 11:43:20,166 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/odata].[Resteasy]] (http-localhost-127.0.0.1-8080-2) Servlet.service() for servlet Resteasy threw exception: java.lang.NullPointerException > at com.ctc.wstx.sw.BaseStreamWriter.writeCharacters(BaseStreamWriter.java:447) > at org.codehaus.stax2.ri.Stax2EventWriterImpl.add(Stax2EventWriterImpl.java:124) > at org.odata4j.stax2.staximpl.StaxXMLWriter2.writeText(StaxXMLWriter2.java:108) [odata4j-core-0.8.0-SNAPSHOT-redhat.jar:] > at org.odata4j.format.xml.AtomErrorFormatWriter.writeError(AtomErrorFormatWriter.java:31) [odata4j-core-0.8.0-SNAPSHOT-redhat.jar:] > at org.odata4j.format.xml.AtomErrorFormatWriter.write(AtomErrorFormatWriter.java:20) [odata4j-core-0.8.0-SNAPSHOT-redhat.jar:] > at org.odata4j.format.xml.AtomErrorFormatWriter.write(AtomErrorFormatWriter.java:15) [odata4j-core-0.8.0-SNAPSHOT-redhat.jar:] > at org.teiid.odata.ODataExceptionMappingProvider.toResponse(ODataExceptionMappingProvider.java:55) [classes:] > at org.teiid.odata.ODataExceptionMappingProvider.toResponse(ODataExceptionMappingProvider.java:42) [classes:] > at org.jboss.resteasy.core.SynchronousDispatcher.executeExceptionMapper(SynchronousDispatcher.java:344) [resteasy-jaxrs-2.3.7.Final.jar:] > at org.jboss.resteasy.core.SynchronousDispatcher.unwrapException(SynchronousDispatcher.java:373) [resteasy-jaxrs-2.3.7.Final.jar:] > at org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:362) [resteasy-jaxrs-2.3.7.Final.jar:] > at org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:233) [resteasy-jaxrs-2.3.7.Final.jar:] > at org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:209) [resteasy-jaxrs-2.3.7.Final.jar:] > at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:557) [resteasy-jaxrs-2.3.7.Final.jar:] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524) [resteasy-jaxrs-2.3.7.Final.jar:] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126) [resteasy-jaxrs-2.3.7.Final.jar:] > at org.teiid.odata.ODataServletContainerDispatcher.service(ODataServletContainerDispatcher.java:97) [classes:] > at org.teiid.odata.ODataServlet.service(ODataServlet.java:61) [classes:] > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.3.7.Final.jar:] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.13.Final.jar:] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.13.Final.jar:] > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.13.Final.jar:] > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.13.Final.jar:] > at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:489) [jbossweb-7.0.13.Final.jar:] > at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final] > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.13.Final.jar:] > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.13.Final.jar:] > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.13.Final.jar:] > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.13.Final.jar:] > at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.13.Final.jar:] > at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671) [jbossweb-7.0.13.Final.jar:] > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.13.Final.jar:] > at java.lang.Thread.run(Unknown Source) [rt.jar:1.7.0_17] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 11 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues February 2014