September 2015 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-3686) OData DELETE nonexisting row - wrong response code

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-3686?page=com.atlassian.jira.plugin... ] Ramesh Reddy resolved TEIID-3686. --------------------------------- Fix Version/s: 8.12 Resolution: Done Labels: CR1 (was: ) Added check to see if the entity is found or not for delete and update operations, and then return the right response codes success - 200 OK not-found - 404 update-success - 204 no-content > OData DELETE nonexisting row - wrong response code > -------------------------------------------------- > > Key: TEIID-3686 > URL: https://issues.jboss.org/browse/TEIID-3686 > Project: Teiid > Issue Type: Bug > Components: OData > Affects Versions: 8.7.1.6_2 > Reporter: Michal Sanitrak > Assignee: Ramesh Reddy > Labels: CR1 > Fix For: 8.12 > > > I deployed VDB that can be accessed with OData. When I perform DELETE request to remove row for first time response code is 200 OK (maybe it should be 204) but when I repeat the same DELETE request and tried to delete already deleted entry, response is again 200 OK, but it should be 404 Not Found. Same thing happens even I when tried to delete entry with id that doesn't exist at all. > Only indication of this problem is in the server log: > {code:plain}INFO [org.teiid.ODATA] (http-/127.0.0.1:8080-1) no entity to delete in = BooksMySQL.BOOKS with key= ('1') > {code} > I think that response code for deleting row that doesn't exist should be different than 200 OK. > For example the service at odata.org returns following content with response code 404 Not Found: > {code:xml} > <?xml version="1.0" encoding="utf-8" standalone="yes"?> > <error xmlns="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata"> > <code></code> > <message xml:lang="en-US">Resource not found for the segment 'Products'.</message> > </error> > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3559) Refactor Object and Infinispan translator / connectors

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3559?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated TEIID-3559: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1197789 Bugzilla Update: Perform > Refactor Object and Infinispan translator / connectors > ------------------------------------------------------ > > Key: TEIID-3559 > URL: https://issues.jboss.org/browse/TEIID-3559 > Project: Teiid > Issue Type: Task > Components: Misc. Connectors > Reporter: Van Halbert > Assignee: Van Halbert > Priority: Optional > > Now that JDG has reworked its remote-cache and changed (reduced) what dependencies its exposed, there's now more common code between the object/infinispan-cache translator/connector and the infinispan-cache-dsl translator/connector. I think refactoring can eliminate issues with support and ensure common behavior across all the code. > Where is common code seen: > - searching (i.e., DSLSearch) > - updates (InfinispanUpdateExecution) > - ClassRegistry > (for starters) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3559) Refactor Object and Infinispan translator / connectors

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3559?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3559: ------------------------------------------------ Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1197789|https://bugzilla.redhat.com/show_bug.cgi?id=1197789] from NEW to ASSIGNED > Refactor Object and Infinispan translator / connectors > ------------------------------------------------------ > > Key: TEIID-3559 > URL: https://issues.jboss.org/browse/TEIID-3559 > Project: Teiid > Issue Type: Task > Components: Misc. Connectors > Reporter: Van Halbert > Assignee: Van Halbert > Priority: Optional > > Now that JDG has reworked its remote-cache and changed (reduced) what dependencies its exposed, there's now more common code between the object/infinispan-cache translator/connector and the infinispan-cache-dsl translator/connector. I think refactoring can eliminate issues with support and ensure common behavior across all the code. > Where is common code seen: > - searching (i.e., DSLSearch) > - updates (InfinispanUpdateExecution) > - ClassRegistry > (for starters) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3559) Refactor Object and Infinispan translator / connectors

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-3559?page=com.atlassian.jira.plugin... ] Van Halbert commented on TEIID-3559: ------------------------------------ As part of these changes, the support for Lucene searching will be deprecated, in favor of using the JDG DSL query language. This is being done for a couple of reasons: - The DSL querying has better supporting capabilities than lucene searching (as far as the capabilities available right now). - To support Lucene, must also keep upto date with not just JDG, but with the Lucene api changes. So this will simplify maintenance and remove a feature that provided no additional functionality (at this point). If some grand lucene feature was needed, then it can be implemented and used in parallel with DSL. - This will remove overlapping capabilities. > Refactor Object and Infinispan translator / connectors > ------------------------------------------------------ > > Key: TEIID-3559 > URL: https://issues.jboss.org/browse/TEIID-3559 > Project: Teiid > Issue Type: Task > Components: Misc. Connectors > Reporter: Van Halbert > Assignee: Van Halbert > Priority: Optional > > Now that JDG has reworked its remote-cache and changed (reduced) what dependencies its exposed, there's now more common code between the object/infinispan-cache translator/connector and the infinispan-cache-dsl translator/connector. I think refactoring can eliminate issues with support and ensure common behavior across all the code. > Where is common code seen: > - searching (i.e., DSLSearch) > - updates (InfinispanUpdateExecution) > - ClassRegistry > (for starters) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3662) IN predicate against a materialized/temp table index without an order by returns wrong results

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3662?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3662: ------------------------------------------------ Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1257964|https://bugzilla.redhat.com/show_bug.cgi?id=1257964] from MODIFIED to ON_QA > IN predicate against a materialized/temp table index without an order by returns wrong results > ---------------------------------------------------------------------------------------------- > > Key: TEIID-3662 > URL: https://issues.jboss.org/browse/TEIID-3662 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.7 > Reporter: Tom Arnold > Assignee: Steven Hawkins > Priority: Blocker > Fix For: 8.7.1.6_2, 8.12, 8.11.3 > > > Seeing strange behavior when doing a simple select from {{SPATIAL_REF_SYS}}. > This works as expected: > {code} > select srid, proj4text from spatial_ref_sys where srid in (3875,4326); > srid | proj4text > ------+---------------------------------------------------------------------------------------------------------------- > 3875 | +proj=tmerc +lat_0=0 +lon_0=21 +k=1 +x_0=21500000 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs > 4326 | +proj=longlat +datum=WGS84 +no_defs > (2 rows) > {code} > Swapping the values in the IN causes only one row to be returned. > {code} > select srid, proj4text from spatial_ref_sys where srid in (4326,3875); > srid | proj4text > ------+------------------------------------- > 4326 | +proj=longlat +datum=WGS84 +no_defs > (1 row) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3662) IN predicate against a materialized/temp table index without an order by returns wrong results

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3662?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3662: ------------------------------------------------ Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1257964|https://bugzilla.redhat.com/show_bug.cgi?id=1257964] from NEW to MODIFIED > IN predicate against a materialized/temp table index without an order by returns wrong results > ---------------------------------------------------------------------------------------------- > > Key: TEIID-3662 > URL: https://issues.jboss.org/browse/TEIID-3662 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.7 > Reporter: Tom Arnold > Assignee: Steven Hawkins > Priority: Blocker > Fix For: 8.7.1.6_2, 8.12, 8.11.3 > > > Seeing strange behavior when doing a simple select from {{SPATIAL_REF_SYS}}. > This works as expected: > {code} > select srid, proj4text from spatial_ref_sys where srid in (3875,4326); > srid | proj4text > ------+---------------------------------------------------------------------------------------------------------------- > 3875 | +proj=tmerc +lat_0=0 +lon_0=21 +k=1 +x_0=21500000 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs > 4326 | +proj=longlat +datum=WGS84 +no_defs > (2 rows) > {code} > Swapping the values in the IN causes only one row to be returned. > {code} > select srid, proj4text from spatial_ref_sys where srid in (4326,3875); > srid | proj4text > ------+------------------------------------- > 4326 | +proj=longlat +datum=WGS84 +no_defs > (1 row) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3685) org.teiid.padSpace does not affect to the "IN" operator

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3685?page=com.atlassian.jira.plugin... ] Work on TEIID-3685 started by Steven Hawkins. --------------------------------------------- > org.teiid.padSpace does not affect to the "IN" operator > ------------------------------------------------------- > > Key: TEIID-3685 > URL: https://issues.jboss.org/browse/TEIID-3685 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.7.1 > Environment: JBoss DV 6.1.2 > Reporter: hisao furuichi > Assignee: Steven Hawkins > Attachments: datasert.csv, INTERNAL_TEST.zip > > > org.teiid.padSpace does affect to "=" operator. But does not affect to "IN" operator. > [data for a column named "id"] > {noformat} > "test1 " > {noformat} > ["=" operator] I can get a result > {noformat} > SELECT * FROM ViewModel.originalViewTable WHERE ViewModel.originalViewTable.id ='TEST1'; > {noformat} > ["IN" operator] I can not get a result > {noformat} > SELECT * FROM ViewModel.originalViewTable WHERE ViewModel.originalViewTable.id IN ('TEST1', 'TEST2'); > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3686) OData DELETE nonexisting row - wrong response code

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3686?page=com.atlassian.jira.plugin... ] Steven Hawkins reassigned TEIID-3686: ------------------------------------- Assignee: Ramesh Reddy (was: Steven Hawkins) Looks like an OData4J issue as it hardcodes a 200 response in EntityRequestResource. > OData DELETE nonexisting row - wrong response code > -------------------------------------------------- > > Key: TEIID-3686 > URL: https://issues.jboss.org/browse/TEIID-3686 > Project: Teiid > Issue Type: Bug > Components: OData > Affects Versions: 8.7.1.6_2 > Reporter: Michal Sanitrak > Assignee: Ramesh Reddy > > I deployed VDB that can be accessed with OData. When I perform DELETE request to remove row for first time response code is 200 OK (maybe it should be 204) but when I repeat the same DELETE request and tried to delete already deleted entry, response is again 200 OK, but it should be 404 Not Found. Same thing happens even I when tried to delete entry with id that doesn't exist at all. > Only indication of this problem is in the server log: > {code:plain}INFO [org.teiid.ODATA] (http-/127.0.0.1:8080-1) no entity to delete in = BooksMySQL.BOOKS with key= ('1') > {code} > I think that response code for deleting row that doesn't exist should be different than 200 OK. > For example the service at odata.org returns following content with response code 404 Not Found: > {code:xml} > <?xml version="1.0" encoding="utf-8" standalone="yes"?> > <error xmlns="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata"> > <code></code> > <message xml:lang="en-US">Resource not found for the segment 'Products'.</message> > </error> > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3686) OData DELETE nonexisting row - wrong response code

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3686?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated TEIID-3686: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1261027 Bugzilla Update: Perform > OData DELETE nonexisting row - wrong response code > -------------------------------------------------- > > Key: TEIID-3686 > URL: https://issues.jboss.org/browse/TEIID-3686 > Project: Teiid > Issue Type: Bug > Components: OData > Affects Versions: 8.7.1.6_2 > Reporter: Michal Sanitrak > Assignee: Steven Hawkins > > I deployed VDB that can be accessed with OData. When I perform DELETE request to remove row for first time response code is 200 OK (maybe it should be 204) but when I repeat the same DELETE request and tried to delete already deleted entry, response is again 200 OK, but it should be 404 Not Found. Same thing happens even I when tried to delete entry with id that doesn't exist at all. > Only indication of this problem is in the server log: > {code:plain}INFO [org.teiid.ODATA] (http-/127.0.0.1:8080-1) no entity to delete in = BooksMySQL.BOOKS with key= ('1') > {code} > I think that response code for deleting row that doesn't exist should be different than 200 OK. > For example the service at odata.org returns following content with response code 404 Not Found: > {code:xml} > <?xml version="1.0" encoding="utf-8" standalone="yes"?> > <error xmlns="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata"> > <code></code> > <message xml:lang="en-US">Resource not found for the segment 'Products'.</message> > </error> > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3686) OData DELETE nonexisting row - wrong response code

by Michal Sanitrak (JIRA)

Michal Sanitrak created TEIID-3686: -------------------------------------- Summary: OData DELETE nonexisting row - wrong response code Key: TEIID-3686 URL: https://issues.jboss.org/browse/TEIID-3686 Project: Teiid Issue Type: Bug Components: OData Affects Versions: 8.7.1.6_2 Reporter: Michal Sanitrak Assignee: Steven Hawkins I deployed VDB that can be accessed with OData. When I perform DELETE request to remove row for first time response code is 200 OK (maybe it should be 204) but when I repeat the same DELETE request and tried to delete already deleted entry, response is again 200 OK, but it should be 404 Not Found. Same thing happens even I when tried to delete entry with id that doesn't exist at all. Only indication of this problem is in the server log: {code:plain}INFO [org.teiid.ODATA] (http-/127.0.0.1:8080-1) no entity to delete in = BooksMySQL.BOOKS with key= ('1') {code} I think that response code for deleting row that doesn't exist should be different than 200 OK. For example the service at odata.org returns following content with response code 404 Not Found: {code:xml} <?xml version="1.0" encoding="utf-8" standalone="yes"?> <error xmlns="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata"> <code></code> <message xml:lang="en-US">Resource not found for the segment 'Products'.</message> </error> {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 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 September 2015