[JBoss JIRA] (TEIID-3808) Informix translator - date/time/timestamp values are adjusted differently according to timezone
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3808?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3808:
------------------------------------------------
David Le Sage <dlesage(a)redhat.com> changed the Status of [bug 1278724|https://bugzilla.redhat.com/show_bug.cgi?id=1278724] from NEW to ON_QA
> Informix translator - date/time/timestamp values are adjusted differently according to timezone
> -----------------------------------------------------------------------------------------------
>
> Key: TEIID-3808
> URL: https://issues.jboss.org/browse/TEIID-3808
> Project: Teiid
> Issue Type: Quality Risk
> Affects Versions: 8.7.1.6_2
> Reporter: Juraj Duráni
> Assignee: Steven Hawkins
>
> The Informix translator adjusts only time value according to server's timezone. Timestamp values are adjusted only if 'DatabaseTimeZone' property is set. Date values are not adjusted at all.
> I am not sure what is Teiid's logic in this case. Is the difference between server's timezone and database's timezone taken into account? Or only the timezone of the database?
> -------------------
> Server's timezone - GMT+1
> DatabaseTimeZone property - not overridden
> Result:
> |time|date|timestamp|
> |01:00:00|2000-01-01|2000-01-01 00:00:00.0|
> Server's timezone - GMT+5
> DatabaseTimeZone property - not overridden
> Result:
> |time|date|timestamp|
> |05:00:00|2000-01-01|2000-01-01 00:00:00.0|
> Server's timezone - GMT+5
> DatabaseTimeZone property - GMT+1
> Result:
> |time|date|timestamp|
> |01:00:00|2000-01-01|2000-01-01 04:00:00.0|
> Server's timezone - GMT+5
> DatabaseTimeZone property - GMT-1
> Result (int this case
> |time|date|timestamp|
> |23:00:00|2000-01-01|2000-01-01 06:00:00.0|
> Informix:
> {code:sql}
> ...
> datevalue date,
> timevalue datetime hour to fraction(1),
> timestampvalue datetime year to fraction(1),
> ...
> {code}
> VDB - foreign table:
> {code:sql}
> ...
> DateValue date OPTIONS (NATIVE_TYPE 'date', NAMEINSOURCE 'datevalue'),
> TimeValue timestamp OPTIONS (NATIVE_TYPE 'datetime hour to fraction(1)', NAMEINSOURCE 'timevalue'),
> TimestampValue timestamp OPTIONS (NATIVE_TYPE 'datetime year to fraction(1)', NAMEINSOURCE 'timestampvalue'),
> ...
> {code}
> VDB - view:
> {code:sql}
> ...
> DateValue date,
> TimeValue time,
> TimestampValue timestamp,
> ...
> AS ... DateValue, convert(TimeValue, time), TimestampValue, ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (TEIID-4271) Consume Teiid OData from Salesforce
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-4271?page=com.atlassian.jira.plugin... ]
Ramesh Reddy reassigned TEIID-4271:
-----------------------------------
Assignee: Ramesh Reddy (was: Johnathon Lee)
> Consume Teiid OData from Salesforce
> -----------------------------------
>
> Key: TEIID-4271
> URL: https://issues.jboss.org/browse/TEIID-4271
> Project: Teiid
> Issue Type: Feature Request
> Components: OData
> Reporter: Steven Hawkins
> Assignee: Ramesh Reddy
> Fix For: 8.12.x
>
>
> At least when consuming OData 2, Salesforce does not support Collection(Int16|Int32|String). Since we expose our system metadata, including pg metadata, in the OData metadata, this means that Salesforce won't consume. If the pg metadata is disabled and there are not primitive array columns in the rest of the metadata, then Salesforce can consume.
> Since this is working around a Salesforce issue, we shouldn't introduce too intrusive of a mechanism for this. And in general we may need to use extension metadata to allow users to exclude objects in a more granular way from being exposed in OData metadata.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (TEIID-4271) Consume Teiid OData from Salesforce
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-4271?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-4271:
-------------------------------------
OK, I will correct the logic.
> Consume Teiid OData from Salesforce
> -----------------------------------
>
> Key: TEIID-4271
> URL: https://issues.jboss.org/browse/TEIID-4271
> Project: Teiid
> Issue Type: Feature Request
> Components: OData
> Reporter: Steven Hawkins
> Assignee: Johnathon Lee
> Fix For: 8.12.x
>
>
> At least when consuming OData 2, Salesforce does not support Collection(Int16|Int32|String). Since we expose our system metadata, including pg metadata, in the OData metadata, this means that Salesforce won't consume. If the pg metadata is disabled and there are not primitive array columns in the rest of the metadata, then Salesforce can consume.
> Since this is working around a Salesforce issue, we shouldn't introduce too intrusive of a mechanism for this. And in general we may need to use extension metadata to allow users to exclude objects in a more granular way from being exposed in OData metadata.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (TEIID-4271) Consume Teiid OData from Salesforce
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4271?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-4271:
---------------------------------------
> What I can't seem to understand advantages why you proposing new solution over what I provided, which is general purpose in nature and works in both situations.
Because from a user perspective you have to update a property one time - not for each vdb/version, and yes hiding any other schema from odata as you say could be accomplished with a hidden schema.
> Again the solution is more targeted for SF.
exclude-system-schema is not, but yes salesforce-safe-metadata is. However it's unlikely that a user would want to omit/hide an entire schema because a single table/procedure contained an array type, so a targeted solution is probably what would needed outside of the system schema (which as we've already agreed can easily be omitted).
> SF might come along their support for Collections in next release, so, IMO we do not need to specifically target for that.
That is what I am saying - you would validate the sf integration before adding salesforce-safe-metadata to later branches.
What I'm advocating for is to just do exclude-system-schema for legacy branches. If you feel like that seems incomplete, then I'm saying salesforce-safe-metadata is the next best solution.
> Consume Teiid OData from Salesforce
> -----------------------------------
>
> Key: TEIID-4271
> URL: https://issues.jboss.org/browse/TEIID-4271
> Project: Teiid
> Issue Type: Feature Request
> Components: OData
> Reporter: Steven Hawkins
> Assignee: Johnathon Lee
> Fix For: 8.12.x
>
>
> At least when consuming OData 2, Salesforce does not support Collection(Int16|Int32|String). Since we expose our system metadata, including pg metadata, in the OData metadata, this means that Salesforce won't consume. If the pg metadata is disabled and there are not primitive array columns in the rest of the metadata, then Salesforce can consume.
> Since this is working around a Salesforce issue, we shouldn't introduce too intrusive of a mechanism for this. And in general we may need to use extension metadata to allow users to exclude objects in a more granular way from being exposed in OData metadata.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (TEIID-4271) Consume Teiid OData from Salesforce
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-4271?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-4271:
-------------------------------------
What I can't seem to understand advantages why you proposing new solution over what I provided, which is general purpose in nature and works in both situations. I am placing this as feature where user has a way to exclude a schema based on their choice, rather than specific Salesforce specific. I advantage I see is, you will not eliminate whole schema, but only ones with collections types. Again the solution is more targeted for SF. SF might come along their support for Collections in next release, so, IMO we do not need to specifically target for that.
One argument I can agree is, with visibility of the models we can control the schema inclusion already, then why a generic solution over it? The reason I did this way is, so that I can give choice to the user per VDB whether one could choose to hide system metadata or not. If you think that distinction is not really necessary then I am OK with changing to "exclude-system-metadata" property.
As per V4, it is not given that SF do not support Collections, AFAIK they do not have V4 support or there is no such limitation, so IMO there is no action needed there yet. If it proven that we need it then we can further look into the issue.
> Consume Teiid OData from Salesforce
> -----------------------------------
>
> Key: TEIID-4271
> URL: https://issues.jboss.org/browse/TEIID-4271
> Project: Teiid
> Issue Type: Feature Request
> Components: OData
> Reporter: Steven Hawkins
> Assignee: Johnathon Lee
> Fix For: 8.12.x
>
>
> At least when consuming OData 2, Salesforce does not support Collection(Int16|Int32|String). Since we expose our system metadata, including pg metadata, in the OData metadata, this means that Salesforce won't consume. If the pg metadata is disabled and there are not primitive array columns in the rest of the metadata, then Salesforce can consume.
> Since this is working around a Salesforce issue, we shouldn't introduce too intrusive of a mechanism for this. And in general we may need to use extension metadata to allow users to exclude objects in a more granular way from being exposed in OData metadata.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (TEIID-4271) Consume Teiid OData from Salesforce
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4271?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-4271:
---------------------------------------
To refine what I'm saying, there are two properties I would be in favor of:
exclude-system-schema - for OData 2 in legacy branches.
And/or
salesforce-safe-metadata - which could exclude the system metadata and any table / procedure with an array type.
And we would validate if salesforce-safe-metadata is even needed for OData 4.
> Consume Teiid OData from Salesforce
> -----------------------------------
>
> Key: TEIID-4271
> URL: https://issues.jboss.org/browse/TEIID-4271
> Project: Teiid
> Issue Type: Feature Request
> Components: OData
> Reporter: Steven Hawkins
> Assignee: Johnathon Lee
> Fix For: 8.12.x
>
>
> At least when consuming OData 2, Salesforce does not support Collection(Int16|Int32|String). Since we expose our system metadata, including pg metadata, in the OData metadata, this means that Salesforce won't consume. If the pg metadata is disabled and there are not primitive array columns in the rest of the metadata, then Salesforce can consume.
> Since this is working around a Salesforce issue, we shouldn't introduce too intrusive of a mechanism for this. And in general we may need to use extension metadata to allow users to exclude objects in a more granular way from being exposed in OData metadata.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[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:
------------------------------------------------
Lucie Fabrikova <lfabriko(a)redhat.com> changed the Status of [bug 1197789|https://bugzilla.redhat.com/show_bug.cgi?id=1197789] from ON_QA to VERIFIED
> 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
> Fix For: 9.0, 8.12.5
>
>
> 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)
9 years, 8 months
[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 ASSIGNED to ON_QA
> 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
> Fix For: 9.0, 8.12.5
>
>
> 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)
9 years, 8 months
[JBoss JIRA] (TEIID-4367) Fail to deploy VDB with TextTable SELECTOR
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4367?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-4367.
-----------------------------------
Resolution: Done
Thanks Lucie for finding this.
Corrected the to string logic.
> Fail to deploy VDB with TextTable SELECTOR
> ------------------------------------------
>
> Key: TEIID-4367
> URL: https://issues.jboss.org/browse/TEIID-4367
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.7
> Reporter: Lucie Fabrikova
> Assignee: Steven Hawkins
> Fix For: 9.1
>
> Attachments: texttabvdb-vdb.xml
>
>
> Server fails to deploy dynamic vdb with models which contain following TextTable parameter: SELECTOR.
> Server log:
> 14:50:56,219 INFO [org.teiid.RUNTIME] (teiid-async-threads - 2) TEIID50030 VDB texttab.1 model "model5" metadata loaded. End Time: 8/1/16 2:50 PM
> 14:50:56,220 INFO [org.teiid.RUNTIME] (teiid-async-threads - 1) TEIID50030 VDB texttab.1 model "model3" metadata loaded. End Time: 8/1/16 2:50 PM
> 14:50:56,227 WARN [org.teiid.PLANNER.RESOLVER] (teiid-async-threads - 2) TEIID31080 model5.v3 validation error: TEIID31100 Parsing error: Encountered "('a' SELECTOR [*]a[*] COLUMNS y" at line 1, column 40.
> Was expecting: <STRINGVAL>
> 14:50:56,228 INFO [org.teiid.RUNTIME] (teiid-async-threads - 2) TEIID40073 The metadata for the VDB texttab.1 is loaded, however it is not valid. Check models for errors. Correct the metadata and re-deploy.
> 14:50:56,228 INFO [org.teiid.RUNTIME.VDBLifeCycleListener] (teiid-async-threads - 2) TEIID40003 VDB texttab.1 is set to FAILED
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (TEIID-4367) Fail to deploy VDB with TextTable SELECTOR
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4367?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-4367:
----------------------------------
Component/s: Query Engine
> Fail to deploy VDB with TextTable SELECTOR
> ------------------------------------------
>
> Key: TEIID-4367
> URL: https://issues.jboss.org/browse/TEIID-4367
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.7
> Reporter: Lucie Fabrikova
> Assignee: Steven Hawkins
> Fix For: 9.1
>
> Attachments: texttabvdb-vdb.xml
>
>
> Server fails to deploy dynamic vdb with models which contain following TextTable parameter: SELECTOR.
> Server log:
> 14:50:56,219 INFO [org.teiid.RUNTIME] (teiid-async-threads - 2) TEIID50030 VDB texttab.1 model "model5" metadata loaded. End Time: 8/1/16 2:50 PM
> 14:50:56,220 INFO [org.teiid.RUNTIME] (teiid-async-threads - 1) TEIID50030 VDB texttab.1 model "model3" metadata loaded. End Time: 8/1/16 2:50 PM
> 14:50:56,227 WARN [org.teiid.PLANNER.RESOLVER] (teiid-async-threads - 2) TEIID31080 model5.v3 validation error: TEIID31100 Parsing error: Encountered "('a' SELECTOR [*]a[*] COLUMNS y" at line 1, column 40.
> Was expecting: <STRINGVAL>
> 14:50:56,228 INFO [org.teiid.RUNTIME] (teiid-async-threads - 2) TEIID40073 The metadata for the VDB texttab.1 is loaded, however it is not valid. Check models for errors. Correct the metadata and re-deploy.
> 14:50:56,228 INFO [org.teiid.RUNTIME.VDBLifeCycleListener] (teiid-async-threads - 2) TEIID40003 VDB texttab.1 is set to FAILED
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months