February 2016 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-3938) EdmDate and EdmTimeOfDay output in local timezone

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3938?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3938: --------------------------------------- If there is agreement that Edm.Date and Edm.TimeOfDay should default to GMT in/out, then a property isn't needed unless you are trying to maintain backwards compatibility. I was thinking when I first looked at the patch that your flag on EdmDateTimeOffset changed the actual value, but it just selects between equivalent string forms for the same instant. A flag for Edm.Date and Edm.TimeOfDay would actually change the values. > EdmDate and EdmTimeOfDay output in local timezone > ------------------------------------------------- > > Key: TEIID-3938 > URL: https://issues.jboss.org/browse/TEIID-3938 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Fix For: 8.12.5 > > > EdmDate and EdmTimeOfDay both assume GMT for incoming string values - however when the convert from Java objects to string they use the local/default Calendar. So when Teiid is on a server not in GMT date and time value sent via the odata4 translator will likely be wrong. > Ramesh: > I have posted a question to the Olingo development group here http://markmail.org/search/list:org.apache.olingo.dev#query:list%3Aorg.ap... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-3938) EdmDate and EdmTimeOfDay output in local timezone

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-3938?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-3938: ------------------------------------- [~shawkins] On second thought you are correct, I should have treated the Edm.Date and Edm.TimeOfDay similarly for converting to string. I will post another update in little while. > EdmDate and EdmTimeOfDay output in local timezone > ------------------------------------------------- > > Key: TEIID-3938 > URL: https://issues.jboss.org/browse/TEIID-3938 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Fix For: 8.12.5 > > > EdmDate and EdmTimeOfDay both assume GMT for incoming string values - however when the convert from Java objects to string they use the local/default Calendar. So when Teiid is on a server not in GMT date and time value sent via the odata4 translator will likely be wrong. > Ramesh: > I have posted a question to the Olingo development group here http://markmail.org/search/list:org.apache.olingo.dev#query:list%3Aorg.ap... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-3934) Additional must pushdown support

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3934?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-3934: ---------------------------------- Issue Type: Enhancement (was: Feature Request) > Additional must pushdown support > -------------------------------- > > Key: TEIID-3934 > URL: https://issues.jboss.org/browse/TEIID-3934 > Project: Teiid > Issue Type: Enhancement > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.0 > > > TEIID-3227 effectively addressed subexpressions within aggregate functions. This should be more generally expanded.. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-3934) Additional must pushdown support

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3934?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-3934. ----------------------------------- Resolution: Done Updated the assign output logic and the evaluator to look for must pushdown function subexpressions that can be pushed. > Additional must pushdown support > -------------------------------- > > Key: TEIID-3934 > URL: https://issues.jboss.org/browse/TEIID-3934 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.0 > > > TEIID-3227 effectively addressed subexpressions within aggregate functions. This should be more generally expanded.. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-3938) EdmDate and EdmTimeOfDay output in local timezone

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3938?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3938: --------------------------------------- > EdmDateTimeOffset has Timezone information, but tests are written such that they expected "GMT" Yes, that make sense. With a different default timezone the string forms would be different, but the values would be functionally the same. So you are just forcing it into GMT. > EdmDate and EdmTimeOfDay output in local timezone > ------------------------------------------------- > > Key: TEIID-3938 > URL: https://issues.jboss.org/browse/TEIID-3938 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Fix For: 8.12.5 > > > EdmDate and EdmTimeOfDay both assume GMT for incoming string values - however when the convert from Java objects to string they use the local/default Calendar. So when Teiid is on a server not in GMT date and time value sent via the odata4 translator will likely be wrong. > Ramesh: > I have posted a question to the Olingo development group here http://markmail.org/search/list:org.apache.olingo.dev#query:list%3Aorg.ap... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-3938) EdmDate and EdmTimeOfDay output in local timezone

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-3938?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-3938: ------------------------------------- EdmDateTimeOffset has Timezone information, but tests are written such that they expected "GMT", but there were series of conversions between default time zone and GMT to make all work. So, I simply removed the GMT for EdmdatTimeOffset and let the TZ set on the object take precedence. For unit tests I introduced system property, to convert back to GMT. Where as Edm.Date and Edm.TimeOfDay do not have TZ info, so coming in I assumed they are "GMT", while going out converted the time to GMT and then sent it out. So, I thought the flag is not required here. > EdmDate and EdmTimeOfDay output in local timezone > ------------------------------------------------- > > Key: TEIID-3938 > URL: https://issues.jboss.org/browse/TEIID-3938 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Fix For: 8.12.5 > > > EdmDate and EdmTimeOfDay both assume GMT for incoming string values - however when the convert from Java objects to string they use the local/default Calendar. So when Teiid is on a server not in GMT date and time value sent via the odata4 translator will likely be wrong. > Ramesh: > I have posted a question to the Olingo development group here http://markmail.org/search/list:org.apache.olingo.dev#query:list%3Aorg.ap... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-3947) Incorrect handling of text cells carrying pure numerals in Excel translator

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3947?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3947: --------------------------------------- Based upon all of this, I would vote to resolve this as a KI stating that numeric cells in string columns will be formatted as doubles. Do you concur? > Incorrect handling of text cells carrying pure numerals in Excel translator > --------------------------------------------------------------------------- > > Key: TEIID-3947 > URL: https://issues.jboss.org/browse/TEIID-3947 > Project: Teiid > Issue Type: Bug > Reporter: Vijay Bhaskar Chintalapati > Assignee: Steven Hawkins > Priority: Minor > > When the user intends to retrieve (based on source model) textual data from a column in an Excel spreadsheet and when one or of the cells are pure numbers, what gets returned is the string representation of the double representation of the number. > For example: If the cell has 1234, instead of returning 1234 Apache POI and DV returns 1234.0 > Adding more detail below from a Email sent as part of client update: > After a thorough investigation into the issue it was found that JDV relies on Apache POI APIs to get the cell content . According to the link [1], Apache POI will return the cell type as double by default when asked for the cell type and when asked for the value will return the double value. JDV is doing its due diligence of converting the value to String [2] but by then POI has already returned 11.0 for a cell value of 11. And converting 11.0 to String will still keep it at > 11.0. > What should ideally happen, in my opinion is, the double should be compared against its Long equivalent and see if they are the same. If Yes, then the cell value should be extracted as string disregarding the type associated with the cell. This is because regardless of how you try to maintain a cell text value of 11.0, Excel always saves (don't confuse this with how it shows) it as 11. > [1] https://poi.apache.org/apidocs/org/apache/poi/ss/usermodel/Cell.html > [2] https://goo.gl/nC3XoG -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-3938) EdmDate and EdmTimeOfDay output in local timezone

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3938?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3938: --------------------------------------- Is there a reason for the system property with EdmDateTimeOffset and not the other types? You could also simplify things in EdmDateTimeOffset: {code} Calendar dateTimeValue = null; // normalize to GMT for output if (Boolean.getBoolean("normalizeEdmDateTimeOffsetToGMT")) { dateTimeValue = createDateTimeInGMT(value); } else { dateTimeValue = createDateTime(value); } {code} And move createDateInGMT method to EdmDateTimeOffset as createDateTimeInGMT. You can also avoid creating the additional Calendar in createDateTimeInGMT in the Calendar case, but that's a very minor concern. > EdmDate and EdmTimeOfDay output in local timezone > ------------------------------------------------- > > Key: TEIID-3938 > URL: https://issues.jboss.org/browse/TEIID-3938 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Fix For: 8.12.5 > > > EdmDate and EdmTimeOfDay both assume GMT for incoming string values - however when the convert from Java objects to string they use the local/default Calendar. So when Teiid is on a server not in GMT date and time value sent via the odata4 translator will likely be wrong. > Ramesh: > I have posted a question to the Olingo development group here http://markmail.org/search/list:org.apache.olingo.dev#query:list%3Aorg.ap... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-3938) EdmDate and EdmTimeOfDay output in local timezone

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-3938?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-3938: ------------------------------------- [~shawkins] can you take look at this patch, if think this is good, then I will submit to Olingo folks. https://github.com/rareddy/olingo-odata4/commit/d1938c0a92cb3cbba1a31f8b5... > EdmDate and EdmTimeOfDay output in local timezone > ------------------------------------------------- > > Key: TEIID-3938 > URL: https://issues.jboss.org/browse/TEIID-3938 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Fix For: 8.12.5 > > > EdmDate and EdmTimeOfDay both assume GMT for incoming string values - however when the convert from Java objects to string they use the local/default Calendar. So when Teiid is on a server not in GMT date and time value sent via the odata4 translator will likely be wrong. > Ramesh: > I have posted a question to the Olingo development group here http://markmail.org/search/list:org.apache.olingo.dev#query:list%3Aorg.ap... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-3938) EdmDate and EdmTimeOfDay output in local timezone

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-3938?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-3938: ------------------------------------- This issue sending round n round again with Olingo. There are lots of tests failing. They wrote for consumption the GMT is assumed, but on production side there the timezone set on the Time/Date/Timestamp is assumed. In cases of Edm.Date and Edm.TimeOfDay, I am going to convert them to GMT based time object then output the string form of it. > EdmDate and EdmTimeOfDay output in local timezone > ------------------------------------------------- > > Key: TEIID-3938 > URL: https://issues.jboss.org/browse/TEIID-3938 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Fix For: 8.12.5 > > > EdmDate and EdmTimeOfDay both assume GMT for incoming string values - however when the convert from Java objects to string they use the local/default Calendar. So when Teiid is on a server not in GMT date and time value sent via the odata4 translator will likely be wrong. > Ramesh: > I have posted a question to the Olingo development group here http://markmail.org/search/list:org.apache.olingo.dev#query:list%3Aorg.ap... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues February 2016