[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:
----------------------------------------
Another observation: the reformatting seems to depend on the value of mm/dd:
# for values <1,12> like 1994-01-17, the date is reformatted to 01/17/1994
# for other values like 1994-01-07, the update switches day and month producing: 1994-07-01
> 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)
6 years, 11 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/28/17 11:34 PM:
------------------------------------------------------------------
Another observation: the reformatting seems to depend on the value of mm/dd:
# for values of day/month within interval <1,12> like 1994-01-17, the date is reformatted to 01/17/1994
# for other values like 1994-01-07, the update switches day and month producing: 1994-07-01
was (Author: lfabriko):
Another observation: the reformatting seems to depend on the value of mm/dd:
# for values <1,12> like 1994-01-17, the date is reformatted to 01/17/1994
# for other values like 1994-01-07, the update switches day and month producing: 1994-07-01
> 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)
6 years, 11 months
[JBoss JIRA] (TEIID-4880) Join Elimination in Star Schema
by Madou Coulibaly (JIRA)
[ https://issues.jboss.org/browse/TEIID-4880?page=com.atlassian.jira.plugin... ]
Madou Coulibaly updated TEIID-4880:
-----------------------------------
Description:
Suppose we have the following star schema :
* Fact_Sales (Fact table)
* Dim_Date, Dim_Store and Dim_Product (Dimension tables)
Each table has a PK (id field)
Fact_Sales has a foreign key for each dimension (date_id, store_id, product_id) in order to link them.
Then, suppose we create an aggregate view of the fact table and its dimensions:
SELECT
*
FROM Fact_Sales F
INNER JOIN Dim_Date D ON (F.Date_Id = D.Id)
INNER JOIN Dim_Store S ON (F.Store_Id = S.Id)
INNER JOIN Dim_Product P ON (F.Product_Id = P.Id)
Suppose now we only project fields from the fact table (Fact_Sales) and just one of its dimension (Dim_Product) in a query:
SELECT
Fact_Sales.<fields>, Dim_Product.<fields>
FROM aggregate_view
During the Query Optimization, Teiid should be able to use the PK_FK constraints which link the fact table with its dimension in order to deduct that no fields from the other dimensions (Dim_Date, Dim_Store) are projected so the joins with these tables can be removed for the Query Plan.
was:
Suppose we have the following star schema :
* Fact_Sales (Fact table)
* Dim_Date, Dim_Store and Dim_Product (Dimension tables)
Each table has a PK (id field)
Fact_Sales has a foreign key for each dimension (date_id, store_id, product_id) in order to link them.
Then, suppose we create an aggregate view of the fact table and its dimensions:
_SELECT
*
FROM Fact_Sales F
INNER JOIN Dim_Date D ON (F.Date_Id = D.Id)
INNER JOIN Dim_Store S ON (F.Store_Id = S.Id)
INNER JOIN Dim_Product P ON (F.Product_Id = P.Id)_
Suppose now we only project fields from the fact table (Fact_Sales) and just one of its dimension (Dim_Product) in a query:
_SELECT
Fact_Sales.*, Dim_Product.*
FROM aggregate_view_
During the Query Optimization, Teiid should be able to use the PK_FK constraints which link the fact table with its dimension in order to deduct that no fields from the other dimensions (Dim_Date, Dim_Store) are projected so the joins with these tables can be removed for the Query Plan.
> Join Elimination in Star Schema
> -------------------------------
>
> Key: TEIID-4880
> URL: https://issues.jboss.org/browse/TEIID-4880
> Project: Teiid
> Issue Type: Feature Request
> Components: Query Engine
> Affects Versions: 8.7.11.6_2
> Reporter: Madou Coulibaly
> Assignee: Steven Hawkins
>
> Suppose we have the following star schema :
> * Fact_Sales (Fact table)
> * Dim_Date, Dim_Store and Dim_Product (Dimension tables)
> Each table has a PK (id field)
> Fact_Sales has a foreign key for each dimension (date_id, store_id, product_id) in order to link them.
> Then, suppose we create an aggregate view of the fact table and its dimensions:
> SELECT
> *
> FROM Fact_Sales F
> INNER JOIN Dim_Date D ON (F.Date_Id = D.Id)
> INNER JOIN Dim_Store S ON (F.Store_Id = S.Id)
> INNER JOIN Dim_Product P ON (F.Product_Id = P.Id)
> Suppose now we only project fields from the fact table (Fact_Sales) and just one of its dimension (Dim_Product) in a query:
> SELECT
> Fact_Sales.<fields>, Dim_Product.<fields>
> FROM aggregate_view
> During the Query Optimization, Teiid should be able to use the PK_FK constraints which link the fact table with its dimension in order to deduct that no fields from the other dimensions (Dim_Date, Dim_Store) are projected so the joins with these tables can be removed for the Query Plan.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 11 months
[JBoss JIRA] (TEIID-4880) Join Elimination in Star Schema
by Madou Coulibaly (JIRA)
[ https://issues.jboss.org/browse/TEIID-4880?page=com.atlassian.jira.plugin... ]
Madou Coulibaly updated TEIID-4880:
-----------------------------------
Description:
Suppose we have the following star schema :
* Fact_Sales (Fact table)
* Dim_Date, Dim_Store and Dim_Product (Dimension tables)
Each table has a PK (id field)
Fact_Sales has a foreign key for each dimension (date_id, store_id, product_id) in order to link them.
Then, suppose we create an aggregate view of the fact table and its dimensions:
_SELECT
*
FROM Fact_Sales F
INNER JOIN Dim_Date D ON (F.Date_Id = D.Id)
INNER JOIN Dim_Store S ON (F.Store_Id = S.Id)
INNER JOIN Dim_Product P ON (F.Product_Id = P.Id)_
Suppose now we only project fields from the fact table (Fact_Sales) and just one of its dimension (Dim_Product) in a query:
_SELECT
Fact_Sales.<fields>, Dim_Product.<fields>
FROM aggregate_view_
During the Query Optimization, Teiid should be able to use the PK_FK constraints which link the fact table with its dimension in order to deduct that no fields from the other dimensions (Dim_Date, Dim_Store) are projected so the joins with these tables can be removed for the Query Plan.
was:
Suppose we have the following star schema :
* Fact_Sales (Fact table)
* Dim_Date, Dim_Store and Dim_Product (Dimension tables)
Each table has a PK (id field)
Fact_Sales has a foreign key for each dimension (date_id, store_id, product_id) in order to link them.
Then, suppose we create an aggregate view of the fact table and its dimensions:
SELECT
*
FROM Fact_Sales F
INNER JOIN Dim_Date D ON (F.Date_Id = D.Id)
INNER JOIN Dim_Store S ON (F.Store_Id = S.Id)
INNER JOIN Dim_Product P ON (F.Product_Id = P.Id)
Suppose now we only project fields from the fact table (Fact_Sales) and just one of its dimension (Dim_Product) in a query:
SELECT
Fact_Sales.<fields>, Dim_Product.<fields>
FROM aggregate_view
During the Query Optimization, Teiid should be able to use the PK_FK constraints which link the fact table with its dimension in order to deduct that no fields from the other dimensions (Dim_Date, Dim_Store) are projected so the joins with these tables can be removed for the Query Plan.
> Join Elimination in Star Schema
> -------------------------------
>
> Key: TEIID-4880
> URL: https://issues.jboss.org/browse/TEIID-4880
> Project: Teiid
> Issue Type: Feature Request
> Components: Query Engine
> Affects Versions: 8.7.11.6_2
> Reporter: Madou Coulibaly
> Assignee: Steven Hawkins
>
> Suppose we have the following star schema :
> * Fact_Sales (Fact table)
> * Dim_Date, Dim_Store and Dim_Product (Dimension tables)
> Each table has a PK (id field)
> Fact_Sales has a foreign key for each dimension (date_id, store_id, product_id) in order to link them.
> Then, suppose we create an aggregate view of the fact table and its dimensions:
> _SELECT
> *
> FROM Fact_Sales F
> INNER JOIN Dim_Date D ON (F.Date_Id = D.Id)
> INNER JOIN Dim_Store S ON (F.Store_Id = S.Id)
> INNER JOIN Dim_Product P ON (F.Product_Id = P.Id)_
> Suppose now we only project fields from the fact table (Fact_Sales) and just one of its dimension (Dim_Product) in a query:
> _SELECT
> Fact_Sales.<fields>, Dim_Product.<fields>
> FROM aggregate_view_
> During the Query Optimization, Teiid should be able to use the PK_FK constraints which link the fact table with its dimension in order to deduct that no fields from the other dimensions (Dim_Date, Dim_Store) are projected so the joins with these tables can be removed for the Query Plan.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 11 months
[JBoss JIRA] (TEIID-4880) Join Elimination in Star Schema
by Madou Coulibaly (JIRA)
[ https://issues.jboss.org/browse/TEIID-4880?page=com.atlassian.jira.plugin... ]
Madou Coulibaly updated TEIID-4880:
-----------------------------------
Description:
Suppose we have the following star schema :
* Fact_Sales (Fact table)
* Dim_Date, Dim_Store and Dim_Product (Dimension tables)
Each table has a PK (id field)
Fact_Sales has a foreign key for each dimension (date_id, store_id, product_id) in order to link them.
Then, suppose we create an aggregate view of the fact table and its dimensions:
SELECT
\*
FROM Fact_Sales F
INNER JOIN Dim_Date D ON (F.Date_Id = D.Id)
INNER JOIN Dim_Store S ON (F.Store_Id = S.Id)
INNER JOIN Dim_Product P ON (F.Product_Id = P.Id)
Suppose now we only project fields from the fact table (Fact_Sales) and just one of its dimension (Dim_Product) in a query:
SELECT
Fact_Sales.<fields>, Dim_Product.<fields>
FROM aggregate_view
During the Query Optimization, Teiid should be able to use the PK_FK constraints which link the fact table with its dimension in order to deduct that no fields from the other dimensions (Dim_Date, Dim_Store) are projected so the joins with these tables can be removed for the Query Plan.
was:
Suppose we have the following star schema :
* Fact_Sales (Fact table)
* Dim_Date, Dim_Store and Dim_Product (Dimension tables)
Each table has a PK (id field)
Fact_Sales has a foreign key for each dimension (date_id, store_id, product_id) in order to link them.
Then, suppose we create an aggregate view of the fact table and its dimensions:
_SELECT
*
FROM Fact_Sales F
INNER JOIN Dim_Date D ON (F.Date_Id = D.Id)
INNER JOIN Dim_Store S ON (F.Store_Id = S.Id)
INNER JOIN Dim_Product P ON (F.Product_Id = P.Id)_
Suppose now we only project fields from the fact table (Fact_Sales) and just one of its dimension (Dim_Product) in a query:
_SELECT
Fact_Sales.<fields>, Dim_Product.<fields>
FROM aggregate_view_
During the Query Optimization, Teiid should be able to use the PK_FK constraints which link the fact table with its dimension in order to deduct that no fields from the other dimensions (Dim_Date, Dim_Store) are projected so the joins with these tables can be removed for the Query Plan.
> Join Elimination in Star Schema
> -------------------------------
>
> Key: TEIID-4880
> URL: https://issues.jboss.org/browse/TEIID-4880
> Project: Teiid
> Issue Type: Feature Request
> Components: Query Engine
> Affects Versions: 8.7.11.6_2
> Reporter: Madou Coulibaly
> Assignee: Steven Hawkins
>
> Suppose we have the following star schema :
> * Fact_Sales (Fact table)
> * Dim_Date, Dim_Store and Dim_Product (Dimension tables)
> Each table has a PK (id field)
> Fact_Sales has a foreign key for each dimension (date_id, store_id, product_id) in order to link them.
> Then, suppose we create an aggregate view of the fact table and its dimensions:
> SELECT
> \*
> FROM Fact_Sales F
> INNER JOIN Dim_Date D ON (F.Date_Id = D.Id)
> INNER JOIN Dim_Store S ON (F.Store_Id = S.Id)
> INNER JOIN Dim_Product P ON (F.Product_Id = P.Id)
> Suppose now we only project fields from the fact table (Fact_Sales) and just one of its dimension (Dim_Product) in a query:
> SELECT
> Fact_Sales.<fields>, Dim_Product.<fields>
> FROM aggregate_view
> During the Query Optimization, Teiid should be able to use the PK_FK constraints which link the fact table with its dimension in order to deduct that no fields from the other dimensions (Dim_Date, Dim_Store) are projected so the joins with these tables can be removed for the Query Plan.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 11 months
[JBoss JIRA] (TEIID-4880) Join Elimination in Star Schema
by Madou Coulibaly (JIRA)
Madou Coulibaly created TEIID-4880:
--------------------------------------
Summary: Join Elimination in Star Schema
Key: TEIID-4880
URL: https://issues.jboss.org/browse/TEIID-4880
Project: Teiid
Issue Type: Feature Request
Components: Query Engine
Affects Versions: 8.7.11.6_2
Reporter: Madou Coulibaly
Assignee: Steven Hawkins
Suppose we have the following star schema :
* Fact_Sales (Fact table)
* Dim_Date, Dim_Store and Dim_Product (Dimension tables)
Each table has a PK (id field)
Fact_Sales has a foreign key for each dimension (date_id, store_id, product_id) in order to link them.
Then, suppose we create an aggregate view of the fact table and its dimensions:
_SELECT
*
FROM Fact_Sales F
INNER JOIN Dim_Date D ON (F.Date_Id = D.Id)
INNER JOIN Dim_Store S ON (F.Store_Id = S.Id)
INNER JOIN Dim_Product P ON (F.Product_Id = P.Id)_
Suppose now we only project fields from the fact table (Fact_Sales) and just one of its dimension (Dim_Product) in a query:
_SELECT
Fact_Sales.*, Dim_Product.*
FROM aggregate_view_
During the Query Optimization, Teiid should be able to use the PK_FK constraints which link the fact table with its dimension in order to deduct that no fields from the other dimensions (Dim_Date, Dim_Store) are projected so the joins with these tables can be removed for the Query Plan.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 11 months
[JBoss JIRA] (TEIID-4851) Random errors about PostGIS without using it
by Madou Coulibaly (JIRA)
[ https://issues.jboss.org/browse/TEIID-4851?page=com.atlassian.jira.plugin... ]
Madou Coulibaly commented on TEIID-4851:
----------------------------------------
I will provide you more information ASAP
> Random errors about PostGIS without using it
> --------------------------------------------
>
> Key: TEIID-4851
> URL: https://issues.jboss.org/browse/TEIID-4851
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 8.12.8.6_3
> Environment: Squirrel v3.7
> Teiid JDBC 8.13.1
> JDV 6.3.4
> PostgreSQL 9.6
> Reporter: Madou Coulibaly
> Assignee: Steven Hawkins
>
> When I issue queries using SQuirrel, I get the following error at random whereas I do not use any Geo functions:
> Originally TeiidProcessingException 'ERROR: function postgis_full_version() does not exist
> Hint: No function matches the given name and argument types. You might need to add explicit type casts.
> Position: 8' QueryExecutorImpl.java:2455. Enable more detailed logging to see the entire stacktrace.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 11 months
[JBoss JIRA] (TEIID-4878) Upgrade accumulo and solr libraries
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4878?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-4878.
-----------------------------------
Resolution: Done
Solr was upgraded to 6.4.1. To minimize version changes, accumulo was upgraded to 1.7.3. This also required hadoop core to be changed to hadoop common. The connection test logic seems to be based upon logic that is now intended to be more internal to accumulo as typically a ClientContext is not directly constructed and may need to be altered further in the future.
> Upgrade accumulo and solr libraries
> -----------------------------------
>
> Key: TEIID-4878
> URL: https://issues.jboss.org/browse/TEIID-4878
> Project: Teiid
> Issue Type: Task
> Components: Server
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 9.3
>
>
> Related to TEIID-4572 the solr version should be upgraded. To keep the common version of zookeeper however, we also need to upgrade accumulo.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 11 months