[JBoss JIRA] (TEIID-4854) Google translator fails to update timestamp value reformatted after update
by Lucie Fabrikova (JIRA)
[ https://issues.jboss.org/browse/TEIID-4854?page=com.atlassian.jira.plugin... ]
Lucie Fabrikova commented on TEIID-4854:
----------------------------------------
If timestamp value is reformatted, query 'SELECT TimestampValue from SmallA' produces two different results depending on sheet content:
1. If there is no other row (only header and this one), exception is thrown 'Could not convert source column Source.smalla.timestampvalue to the expected runtime type timestamp'
2. if there is present some other row with correctly formatted timestamp value, null is return for reformatted TimeStampValue
> Google translator fails to update timestamp value reformatted after update
> --------------------------------------------------------------------------
>
> Key: TEIID-4854
> URL: https://issues.jboss.org/browse/TEIID-4854
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 9.3, 8.12.10.6_3
> Reporter: Lucie Fabrikova
> Assignee: Steven Hawkins
> Fix For: 9.3
>
> Attachments: gs-reformatted-timestamp.log
>
>
> Cell of type timestamp is reformatted after an update. Data inserted from teiid are in format "yyyy-mm-dd hh:mm:ss[.fffffffff]", which is reformatted to "dd/mm/yyyy hh:mm:ss[.fffffffff]". Subsequent update of such row throws exception "Could not convert source column Source.smalla.timestampvalue to the expected runtime type timestamp".
> Google spreadsheet locale was UK, timezone was set to Berlin.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (TEIID-2820) Support Couchbase as a resource
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-2820?page=com.atlassian.jira.plugin... ]
Kylin Soong edited comment on TEIID-2820 at 4/20/17 10:37 PM:
--------------------------------------------------------------
> what you think of the changes and how you want to resolve the failing test cases.
I have found the failure test all against array table's nested object attribute, but I am NOT consider nested object attribute as a update target, the current update need all demision IDX and documentID, all DX will find the posion of item in array, all attributes in set section will be formed as a JSON object, be used to repleace the current position value.
> Also should there be an issue logged to support upsert?
Yes, upsert should be supported, also the batch insert, I have created TEIID-4873.
was (Author: kylin):
Yes, upsert should be supported, also the batch insert, I would create a JIRA.
> Support Couchbase as a resource
> -------------------------------
>
> Key: TEIID-2820
> URL: https://issues.jboss.org/browse/TEIID-2820
> Project: Teiid
> Issue Type: Feature Request
> Components: Misc. Connectors
> Reporter: Kim Palko
> Assignee: Kylin Soong
> Priority: Blocker
> Labels: data_source
> Fix For: 8.12.x, 9.3
>
>
> Support Couchbase as a data source in Teiid. This requires resource adapter and translater development
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (TEIID-4858) hive translator is extremely slow
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4858?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-4858:
---------------------------------------
Sorry for the delay in following up. Yes the source sql is in there - the difference it that the slow log has an "order by" clause. There does appear to be references to the order by operation not being well optimized on hive, so the simple solution would be to disable order by support on the hive translator with an override:
{code}
<translator name="hive-restricted" type="hive" />
<property name="supportsOrderBy" value="false"/>
</translator>
{code}
And then reference the hive-restricted as the translator for your source.
It would be good to know if there are some other considerations in play here as I wouldn't expect such a difference in performance. Do you see all sorts performing poorly, or perhaps is it related to the data type, or some other factor?
> hive translator is extremely slow
> ---------------------------------
>
> Key: TEIID-4858
> URL: https://issues.jboss.org/browse/TEIID-4858
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 8.12.9.6_3
> Environment: Tested against JDV 6.3.4 and the Cloudera quickstart 5.8 VM with the Cloudera sample data loaded into hive
> Reporter: Michael Echevarria
> Assignee: Steven Hawkins
> Attachments: fast.log, slow.log
>
>
> When querying a table through the hive translator the results take close to 30 seconds to return.
> When querying a table through jdbc default results take under 1 second to return.
> Both use the same underlying jboss server datasource.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (TEIID-4854) Google translator fails to update timestamp value reformatted after update
by Lucie Fabrikova (JIRA)
[ https://issues.jboss.org/browse/TEIID-4854?page=com.atlassian.jira.plugin... ]
Lucie Fabrikova edited comment on TEIID-4854 at 4/20/17 3:58 PM:
-----------------------------------------------------------------
My spreadsheet had locale set to Unigted Kingdom and timezone set to Berlin, with timezone set also to United Kingdom, formatting was left correctly and no issue appeared.
EDIT: there seems to be some undeterminism, I observed the bug even with timezone set e.g. to London.
was (Author: lfabriko):
My spreadsheet had locale set to Unigted Kingdom and timezone set to Berlin, with timezone set also to United Kingdom, formatting was left correctly and no issue appeared.
> Google translator fails to update timestamp value reformatted after update
> --------------------------------------------------------------------------
>
> Key: TEIID-4854
> URL: https://issues.jboss.org/browse/TEIID-4854
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 9.3, 8.12.10.6_3
> Reporter: Lucie Fabrikova
> Assignee: Steven Hawkins
> Fix For: 9.3
>
> Attachments: gs-reformatted-timestamp.log
>
>
> Cell of type timestamp is reformatted after an update. Data inserted from teiid are in format "yyyy-mm-dd hh:mm:ss[.fffffffff]", which is reformatted to "dd/mm/yyyy hh:mm:ss[.fffffffff]". Subsequent update of such row throws exception "Could not convert source column Source.smalla.timestampvalue to the expected runtime type timestamp".
> Google spreadsheet locale was UK, timezone was set to Berlin.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months