[JBoss JIRA] (TEIID-2422) Offer support for a timestampdiff based upon calendar fields
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2422?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2422.
-----------------------------------
Fix Version/s: 8.3
Resolution: Done
Switched timestampdiff to compute differences based upon calendar fields following sql server behavior as closely as possible - documented in the Reference.
There is a switch to use the old Teiid behavior which is in the Admin Guide and mentioned in the release notes.
We are still returning a long from of timestampdiff function (the same as 8.2) rather than an integer, but almost all sources will likely throw an exception if the result is out of the integer range.
With this change however the pushdown to mysql, h2, and mm of timestamp diff may be the wrong result for intervals greater than seconds, thus pushdown of the system timestampdiff was disabled and support for source specific pushdown was added - mysql.timestampdiff etc. where the interval is specified as a literal instead of a keyword. It is a potential compatibility issue if someone wants to use the system timestampdiff and expects pushdown to mysql/h2/mm - but they can always just extend the translator to add timestampdiff to the supported function list.
I did not exhaustively validate all of the other timestampdiff implementations, so there may be other pushdown inconsistencies lurking. The approach would be similar there to disable the system support and add a pushdown function. It may also be desirable eventually to denote which intervals are supported or add compensating logic (such as has been done for fractional seconds) to account for differences in the month/week etc. calculations.
> Offer support for a timestampdiff based upon calendar fields
> ------------------------------------------------------------
>
> Key: TEIID-2422
> URL: https://issues.jboss.org/browse/TEIID-2422
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.3
>
>
> There is little consistency among timestampdiff implementations, however ours seems to be based off of the db2 (http://pic.dhe.ibm.com/infocenter/dzichelp/v2r2/topic/com.ibm.db2z9.doc.s...) timestampdiff in terms of intervals - but does not make all the same assumptions in the calculation of the answer.
> It would be good to provide an option so that our timestampdiff or another system function would calculate differences based upon calendar fields (following the behavior of SQL Server) rather than just based upon the interval - for example the months between 2012-02-20 and 2012-03-01 would report 1 rather than the current answer of 0).
> There is also a general issue with the consistency of the results with the pushdowned versions of timestampdiff as vendor support varies.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (TEIID-2423) add xml deployment for Teiid Embedded
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-2423:
-------------------------------------
Summary: add xml deployment for Teiid Embedded
Key: TEIID-2423
URL: https://issues.jboss.org/browse/TEIID-2423
Project: Teiid
Issue Type: Enhancement
Components: Embedded
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 8.4
We can accept a Reader for the VDBMetadataParser to turn into a VDBMetadata object for deployment (there is already a protected deplyVDB that takes VDBMetadata). There are some additional considerations here, such as allowing for vdb specific connector repositories and the setting of classloaders and other logic typically handled by a server deployment.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (TEIID-2422) Offer support for a timestampdiff based upon calendar fields
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2422?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2422:
---------------------------------------
My thought here is to preserve the current via a config switch (which could be in the dqp config or handled as a hint/vdb scoped) and propose changing the default handling for 8.3 over to the calendar method. The rationale is that the calendar form is more broadly supported (which means more correct pushdown handling - which is currently dubious) and that is consistent with Teiid timestampadd function, which is calendar based.
Generally the same answer will be seen for fractional/second results, but every other interval could return a different answer based upon the values.
> Offer support for a timestampdiff based upon calendar fields
> ------------------------------------------------------------
>
> Key: TEIID-2422
> URL: https://issues.jboss.org/browse/TEIID-2422
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
>
> There is little consistency among timestampdiff implementations, however ours seems to be based off of the db2 (http://pic.dhe.ibm.com/infocenter/dzichelp/v2r2/topic/com.ibm.db2z9.doc.s...) timestampdiff in terms of intervals - but does not make all the same assumptions in the calculation of the answer.
> It would be good to provide an option so that our timestampdiff or another system function would calculate differences based upon calendar fields (following the behavior of SQL Server) rather than just based upon the interval - for example the months between 2012-02-20 and 2012-03-01 would report 1 rather than the current answer of 0).
> There is also a general issue with the consistency of the results with the pushdowned versions of timestampdiff as vendor support varies.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (TEIID-2422) Offer support for a timestampdiff based upon calendar fields
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-2422:
-------------------------------------
Summary: Offer support for a timestampdiff based upon calendar fields
Key: TEIID-2422
URL: https://issues.jboss.org/browse/TEIID-2422
Project: Teiid
Issue Type: Quality Risk
Components: Query Engine
Reporter: Steven Hawkins
Assignee: Steven Hawkins
There is little consistency among timestampdiff implementations, however ours seems to be based off of the db2 (http://pic.dhe.ibm.com/infocenter/dzichelp/v2r2/topic/com.ibm.db2z9.doc.s...) timestampdiff in terms of intervals - but does not make all the same assumptions in the calculation of the answer.
It would be good to provide an option so that our timestampdiff or another system function would calculate differences based upon calendar fields (following the behavior of SQL Server) rather than just based upon the interval - for example the months between 2012-02-20 and 2012-03-01 would report 1 rather than the current answer of 0).
There is also a general issue with the consistency of the results with the pushdowned versions of timestampdiff as vendor support varies.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (TEIID-2421) Allow Designer to ask for stored procedure columns
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2421?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2421.
-----------------------------------
Resolution: Done
added the inferProcedureResultSet parameter which if true will cause the resolver to ignore any existing metadata and instead set the Command.getResultSetColumns from command statement(s) in the procedure.
Leaving the value as false will use the existing metadata, which if there is no resultset parameter defined will not set any resultset columns on the command.
> Allow Designer to ask for stored procedure columns
> --------------------------------------------------
>
> Key: TEIID-2421
> URL: https://issues.jboss.org/browse/TEIID-2421
> Project: Teiid
> Issue Type: Task
> Components: Query Engine
> Affects Versions: 8.2
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.3
>
>
> Successive simplifications to the procedure metadata has left designer without a convenient way to automatically resolve the result set columns for a stored procedure.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (TEIID-2381) Expanded source hint support
by Vineela Gampa (JIRA)
[ https://issues.jboss.org/browse/TEIID-2381?page=com.atlassian.jira.plugin... ]
Vineela Gampa commented on TEIID-2381:
--------------------------------------
Adding another usecase
We have a usecase where we set hints to the transformation query of a view in getMetadata call of a translator. when we are querying for that view we also pass a general hint /*+ sh:'data_window' */. we observed that teiid hints are getting ovveriden. Is there any property with which we can ask teiid to append the hints rather than ovveriding them ?
Below is the snippet of what happens in getMetadata call.
if (v != null) {
v.setVirtual(true);
v.setTableType(Type.View);
String transformation = null;
String localHint = "";
if (hint != null) {
localHint = "/*+ sh:'" + hint + "' */ ";
}
String localCacheHint = "";
if (cacheHint != null) {
localCacheHint = "/*+ " + cacheHint + " */ ";
}
transformation = "SELECT " + localHint + columnList.toString() + " FROM GSV." + tableName + " AS b";
if (cacheHint != null) {
v.setMaterialized(true);
transformation = localCacheHint + transformation;
}
> Expanded source hint support
> ----------------------------
>
> Key: TEIID-2381
> URL: https://issues.jboss.org/browse/TEIID-2381
> Project: Teiid
> Issue Type: Enhancement
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
>
> We currently look at the source hint in only the root user query (not in subqueries nor the with clause) and only consider it in a very narrow set of circumstances when it's used in a view.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (TEIID-2421) Allow Designer to ask for stored procedure columns
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-2421:
-------------------------------------
Summary: Allow Designer to ask for stored procedure columns
Key: TEIID-2421
URL: https://issues.jboss.org/browse/TEIID-2421
Project: Teiid
Issue Type: Task
Components: Query Engine
Affects Versions: 8.2
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 8.3
Successive simplifications to the procedure metadata has left designer without a convenient way to automatically resolve the result set columns for a stored procedure.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (TEIID-2290) Create a Rules (jbpm) quick start
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2290?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-2290:
----------------------------------
Fix Version/s: 8.3.1
(was: 8.3)
Pulling out of the 8.3 bucket as it does not need to hold up the release.
> Create a Rules (jbpm) quick start
> ---------------------------------
>
> Key: TEIID-2290
> URL: https://issues.jboss.org/browse/TEIID-2290
> Project: Teiid
> Issue Type: Task
> Components: Build/Kits
> Reporter: Van Halbert
> Assignee: Van Halbert
> Fix For: 8.3.1
>
>
> Rules integration!
> Calling rules from within virtual procedure or transformation:
> Logical flow something like this:
> For each row
> convert row to array or other form that can be easily passed to
> user-defined function (UDF)
> custom UDF implementation accepts array/vararg params and converts
> to pojo
> UDF injects pojo to knowledge session
> rules (potentially) modify pojo
> UDF converts pojo back to array and returns to Teiid
> procedure/transformation converts array back to record/row
> modified values available to procedure/transformation logic
> End
> Assumptions:
> 1. UDF is not adding or removing columns/fields
> 2. UDF is not changing the datatypes of columns/fields
> 3. overhead of starting knowledge session for each record/row is
> prohibitive. Need a stateful/persistent knowledge session. This may
> mean a rules service of some kind, preferably in-process.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (TEIID-2416) Create a JDBC driver SDK
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2416?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-2416:
----------------------------------
Component/s: Connector API
Query Engine
When should this be targeted? Do we want to first focus on getting a better api for Embedded (mostly around configuring the metadata) or simultaneously produce a tech preview for JDBC development?
Should TEIID-167 be made a subtask of this? And generally do we envision both a rar and non-rar mode? The former could possibly be an enhanced embedded kit with ironjacamar.
> Create a JDBC driver SDK
> ------------------------
>
> Key: TEIID-2416
> URL: https://issues.jboss.org/browse/TEIID-2416
> Project: Teiid
> Issue Type: Feature Request
> Components: Connector API, Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
>
> We should promote an offering of Teiid as just a JDBC toolkit via translator development with an emphasis on a minimal footprint (starting with Embedded, but possibly allowing for the exclusion of large dependencies - primarily saxon, but also xom, nux, etc.).
> More than likely a simplistic configuration scenario via the TeiidDataSource/TeiidDriver would be offered.
> There would be a well-documented and straight-forward migration path to full server deployment as well.
> We should also put more thought into the pass-through sql scenario for additional flexibility in issuing queries.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months