[JBoss JIRA] (TEIID-3829) olingo module junit test failed
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3829?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-3829:
-------------------------------------
[~kylin] Did you see this only in 8.13? or 8.12.x? It does not look specific to 8.13
> olingo module junit test failed
> -------------------------------
>
> Key: TEIID-3829
> URL: https://issues.jboss.org/browse/TEIID-3829
> Project: Teiid
> Issue Type: Bug
> Components: Build/Kits
> Affects Versions: 8.13
> Reporter: Kylin Soong
> Assignee: Ramesh Reddy
> Fix For: 8.13
>
>
> olingo module junit test failed:
> {code}
> Results :
> Failed tests:
> TestODataSQLBuilder.testEq:431->te:400->helpTest:227 expected:<...g0 WHERE g0.e1 = {t'[04]:20:02'} ORDER BY g0...> but was:<...g0 WHERE g0.e1 = {t'[16]:20:02'} ORDER BY g0...>
> TestODataSQLBuilder.testTimeMethods:552->te:400->helpTest:227 expected:<...YEAR({ts'2008-10-13 [04]:20:02.0'}) = 2008 O...> but was:<...YEAR({ts'2008-10-13 [16]:20:02.0'}) = 2008 O...>
> Tests run: 109, Failures: 2, Errors: 0, Skipped: 0
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 1 month
[JBoss JIRA] (TEIID-3829) olingo module junit test failed
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3829?page=com.atlassian.jira.plugin... ]
Ramesh Reddy updated TEIID-3829:
--------------------------------
Parent: (was: TEIID-3519)
Issue Type: Bug (was: Sub-task)
> olingo module junit test failed
> -------------------------------
>
> Key: TEIID-3829
> URL: https://issues.jboss.org/browse/TEIID-3829
> Project: Teiid
> Issue Type: Bug
> Components: Build/Kits
> Affects Versions: 8.13
> Reporter: Kylin Soong
> Assignee: Ramesh Reddy
> Fix For: 8.13
>
>
> olingo module junit test failed:
> {code}
> Results :
> Failed tests:
> TestODataSQLBuilder.testEq:431->te:400->helpTest:227 expected:<...g0 WHERE g0.e1 = {t'[04]:20:02'} ORDER BY g0...> but was:<...g0 WHERE g0.e1 = {t'[16]:20:02'} ORDER BY g0...>
> TestODataSQLBuilder.testTimeMethods:552->te:400->helpTest:227 expected:<...YEAR({ts'2008-10-13 [04]:20:02.0'}) = 2008 O...> but was:<...YEAR({ts'2008-10-13 [16]:20:02.0'}) = 2008 O...>
> Tests run: 109, Failures: 2, Errors: 0, Skipped: 0
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 1 month
[JBoss JIRA] (TEIID-3828) Build failed due to artifact 'org.jboss.oreva:odata-core:jar:0.8.11-SNAPSHOT' can not be resolved
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3828?page=com.atlassian.jira.plugin... ]
Ramesh Reddy resolved TEIID-3828.
---------------------------------
Resolution: Done
Added "1.0.x" branch for 8.13 and beyond. Current "0.8.x" branch for 8.12.x
Released OReva 1.0.0, and using that in 8.13
> Build failed due to artifact 'org.jboss.oreva:odata-core:jar:0.8.11-SNAPSHOT' can not be resolved
> -------------------------------------------------------------------------------------------------
>
> Key: TEIID-3828
> URL: https://issues.jboss.org/browse/TEIID-3828
> Project: Teiid
> Issue Type: Sub-task
> Components: Build/Kits
> Affects Versions: 8.13
> Reporter: Kylin Soong
> Assignee: Ramesh Reddy
> Fix For: 8.13
>
>
> translator-odata use a SNAPSHOT dependency
> {code}
> <dependency>
> <groupId>org.jboss.oreva</groupId>
> <artifactId>odata-core</artifactId>
> </dependency>
> {code}
> which can not be resolved, with the folllowing erros:
> {code}
> [ERROR] Failed to execute goal on project translator-odata: Could not resolve dependencies for project org.jboss.teiid.connectors:translator-odata:bundle:8.13.0.Alpha1-SNAPSHOT: The following artifacts could not be resolved: org.jboss.oreva:odata-core:jar:0.8.11-SNAPSHOT, org.jboss.oreva:common:jar:0.8.11-SNAPSHOT: Failure to find org.jboss.oreva:odata-core:jar:0.8.11-SNAPSHOT in ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 1 month
[JBoss JIRA] (TEIID-3829) olingo module junit test failed
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3829?page=com.atlassian.jira.plugin... ]
Ramesh Reddy reassigned TEIID-3829:
-----------------------------------
Assignee: Ramesh Reddy (was: Steven Hawkins)
> olingo module junit test failed
> -------------------------------
>
> Key: TEIID-3829
> URL: https://issues.jboss.org/browse/TEIID-3829
> Project: Teiid
> Issue Type: Sub-task
> Components: Build/Kits
> Affects Versions: 8.13
> Reporter: Kylin Soong
> Assignee: Ramesh Reddy
> Fix For: 8.13
>
>
> olingo module junit test failed:
> {code}
> Results :
> Failed tests:
> TestODataSQLBuilder.testEq:431->te:400->helpTest:227 expected:<...g0 WHERE g0.e1 = {t'[04]:20:02'} ORDER BY g0...> but was:<...g0 WHERE g0.e1 = {t'[16]:20:02'} ORDER BY g0...>
> TestODataSQLBuilder.testTimeMethods:552->te:400->helpTest:227 expected:<...YEAR({ts'2008-10-13 [04]:20:02.0'}) = 2008 O...> but was:<...YEAR({ts'2008-10-13 [16]:20:02.0'}) = 2008 O...>
> Tests run: 109, Failures: 2, Errors: 0, Skipped: 0
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 1 month
[JBoss JIRA] (TEIID-3831) For results set caching there should scope metadata for source tables/procedures
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-3831:
-------------------------------------
Summary: For results set caching there should scope metadata for source tables/procedures
Key: TEIID-3831
URL: https://issues.jboss.org/browse/TEIID-3831
Project: Teiid
Issue Type: Feature Request
Components: Query Engine
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 8.12.x
Functions have optional metadata to convey their determinism, which affects the caching scope. However we don't have extension metadata or per execution metadata around source queries (there is a scope field on a cache directive, but that only applies to source level caching). We should provide a general mechanism so that users aren't required to manually override the result set cache scope.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 1 month
[JBoss JIRA] (TEIID-3036) Update CXF to current version (3.0.0)
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3036?page=com.atlassian.jira.plugin... ]
Ramesh Reddy reassigned TEIID-3036:
-----------------------------------
Assignee: Ramesh Reddy
> Update CXF to current version (3.0.0)
> -------------------------------------
>
> Key: TEIID-3036
> URL: https://issues.jboss.org/browse/TEIID-3036
> Project: Teiid
> Issue Type: Sub-task
> Components: Embedded
> Affects Versions: 8.8
> Reporter: Gary Gregory
> Assignee: Ramesh Reddy
>
> 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.4.11#64026)
9 years, 1 month
[JBoss JIRA] (TEIID-3627) Infinispan-dsl-cache translator: comparison operators(GE, LE) problem with string
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3627?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3627:
------------------------------------------------
Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1254053|https://bugzilla.redhat.com/show_bug.cgi?id=1254053] from ON_QA to VERIFIED
> Infinispan-dsl-cache translator: comparison operators(GE,LE) problem with string
> --------------------------------------------------------------------------------
>
> Key: TEIID-3627
> URL: https://issues.jboss.org/browse/TEIID-3627
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.7.1.6_2
> Reporter: Jan Stastny
> Assignee: Van Halbert
> Fix For: 8.7.1.6_2, 8.12
>
>
> Comparison of string values provides wrong results for GE and LE operators. I provide example queries, notice the number of rows returned by the queries.
> For query: {code:sql}SELECT BQT1.SmallA.StringNum FROM BQT1.SmallA WHERE BQT1.SmallA.StringNum <= -22 ORDER BY StringNum{code}
> * Process Tree:
> {code:plain}
> LimitNode(0) output=[g_0.stringNum] limit 100
> AccessNode(1) output=[g_0.stringNum] SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.stringNum <= '-22' ORDER BY g_0.stringNum
> {code}
> * SRC CMD: {code:sql}SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.stringNum <= '-22' ORDER BY g_0.stringNum{code}
> * result 0 rows
> But for query: {code:sql}SELECT BQT1.SmallA.StringNum FROM BQT1.SmallA WHERE BQT1.SmallA.StringNum < -22 ORDER BY StringNum{code}
> * Process Tree:
> {code:plain}ProjectNode(0) output=[c.stringNum AS StringNum] [c.stringNum AS StringNum]
> LimitNode(1) output=[c.stringNum] limit 100
> SortNode(2) output=[c.stringNum] [SORT] [c.stringNum]
> SelectNode(3) output=[c.stringNum] c.stringNum < '-22'
> AccessNode(4) output=[c.stringNum] SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0{code}
> * SRC CMD: {code:sql}SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0{code}
> * result 14 rows
> And query: {code:sql}SELECT BQT1.SmallA.StringNum FROM BQT1.SmallA WHERE BQT1.SmallA.StringNum = -22 ORDER BY StringNum{code}
> * Process Tree:
> {code:plain}LimitNode(0) output=[c.stringNum AS StringNum] limit 100
> AccessNode(1) output=[c.stringNum AS StringNum] SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.stringNum = '-22' ORDER BY g_0.stringNum{code}
> * SRC CMD: {code:sql}SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.stringNum = '-22' ORDER BY g_0.stringNum{code}
> * result 1 row
> The first query should then return 15 rows instead of 0. Also the queries differ in a way they are processed, the first one is pushed down to infinispan, the other two are processed by teiid, which is probably a regression originally tracked here: TEIID-3424
> The same cause introduces problems with similar queries:
> {code:sql}Select IntKey, StringKey From BQT1.SmallA WHERE NOT(StringKey > 10 AND IntKey < 47) ORDER BY IntKey{code}
> Which is processed as:
> * Process Tree:
> {code:plain}LimitNode(0) output=[c.intKey AS IntKey, c.stringKey AS StringKey] limit 100
> AccessNode(1) output=[c.intKey AS IntKey, c.stringKey AS StringKey] SELECT g_0.intKey, g_0.stringKey FROM SmallAs.smallARemotecache AS g_0 WHERE (g_0.stringKey <= '10') OR (g_0.intKey >= 47) ORDER BY g_0.intKey{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 1 month