[JBoss JIRA] (TEIID-2458) Sybase15 subquery using HAVING clause failing
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-2458?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated TEIID-2458:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=912548, https://bugzilla.redhat.com/show_bug.cgi?id=996550 (was: https://bugzilla.redhat.com/show_bug.cgi?id=912548)
> Sybase15 subquery using HAVING clause failing
> ---------------------------------------------
>
> Key: TEIID-2458
> URL: https://issues.jboss.org/browse/TEIID-2458
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 7.7
> Reporter: Van Halbert
> Assignee: Steven Hawkins
>
> Example query is failing: SELECT INTKEY, STRINGKEY, FLOATNUM FROM BQT1.SMALLA GROUP BY INTKEY, STRINGKEY, FLOATNUM HAVING FLOATNUM = (SELECT FLOATNUM FROM BQT1.SMALLA WHERE STRINGKEY = 20)
> When this query is submitted through EDS using Squirrel or BQT as a client it returns:
> IntKey StringKey
> 20 20 0
> When the resulting source-specific query generated from EDS is submitted direct to Sybase15 the same results are returned.
> SELECT g_0.IntKey, g_0.StringKey, cast(g_0.FloatNum AS real) FROM SmallA g_0 WHERE cast(g_0.FloatNum AS real) = (SELECT cast(g_1.FloatNum AS real) FROM SmallA g_1 WHERE g_1.StringKey = '20') GROUP BY g_0.IntKey, g_0.StringKey, cast(g_0.FloatNum AS real)is submitted direct to Sybase15
> RESULTS
> IntKey StringKey
> 20 20 0
> However, when the GROUP BY is removed from the query it returns the expected results as shown below:
> IntKey StringKey
> 20 20 -4
> The supporting VDB can be provided if needed.
--
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, 5 months
[JBoss JIRA] (TEIID-2584) Add management features to materialization
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2584?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2584:
---------------------------------------
> What are naming/versioning I should be concerned about?
The vdb name/version would need to be tracked as part of the table name (with some consideration given to allowing the sharing of imported mat views).
Also we may need some kind of collection process that will delete invalid entries out of the status table for vdbs that are missing/undeployed.
> One thing I am struck is, how I could execute this non-blocking manner?
Internally procedures are non-blocking - except when running in a transaction, such as would be the case with an atomic block. In that case we are tied to serial processing.
> Add management features to materialization
> ------------------------------------------
>
> Key: TEIID-2584
> URL: https://issues.jboss.org/browse/TEIID-2584
> Project: Teiid
> Issue Type: Feature Request
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
> Fix For: 8.5
>
>
> Currently Teiid supports internal and external materialization features. The internal is managed completely by the Teiid query engine along with the infinispan cache.
> External materialization is completely unmanaged and left out to the user to manage it externally. This goals for this feature are unify the materialization logic for internal and external, such that both are managed similarly irrespective of the type of materialization chosen.
--
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, 5 months
[JBoss JIRA] (TEIID-2584) Add management features to materialization
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2584?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-2584:
-------------------------------------
> Do you mean you want to write this as a system procedure? I think that could work, but it wouldn't currently give you control of connections. At the least you'd want to use BEGIN ATOMIC
I was thinking write "SYSADMIN" procedure so that we track them admin procedures, but opting to put them in the same schema as the view is. I thought I could use "DYNAMIC SQL" for managing, but realized I need to use procedure language. So, I am adding them as normal virtual procedures. I also changed "load" procedure such that it returns TABLE, which is nothing but loaded materialized view, then I can simply run this procedure to load (if needed) then select the rows needed.
>Are you envisioning a status table on each source per vdb, or a single status table for all of teiid? Each has considerations for table/entry naming/versioning.
By allowing user to define where the status table as the metadata, I left the decision back on to user. It is expectation that they use single copy of it. If used by user, Teiid documentation will provide the table structure that user need to create. (or tooling will fill this gap). What are naming/versioning I should be concerned about?
I am also thinking, if "load" procedure already exists in the schema, the override "load" method should not be generated.
> Are you suggesting that the scripts execute as dynamic sql or against the source native procedure?
native procedures, but expectation is user is wrapping them in the "native" procedure to begin with, such that "load" method is just pre-canned template just replaces the values.
One thing I am struck is, how I could execute this non-blocking manner?
> Add management features to materialization
> ------------------------------------------
>
> Key: TEIID-2584
> URL: https://issues.jboss.org/browse/TEIID-2584
> Project: Teiid
> Issue Type: Feature Request
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
> Fix For: 8.5
>
>
> Currently Teiid supports internal and external materialization features. The internal is managed completely by the Teiid query engine along with the infinispan cache.
> External materialization is completely unmanaged and left out to the user to manage it externally. This goals for this feature are unify the materialization logic for internal and external, such that both are managed similarly irrespective of the type of materialization chosen.
--
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, 5 months
[JBoss JIRA] (TEIID-2584) Add management features to materialization
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2584?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2584:
---------------------------------------
Some questions/thoughts:
> create a "load" procedure like
Do you mean you want to write this as a system procedure? I think that could work, but it wouldn't currently give you control of connections. At the least you'd want to use BEGIN ATOMIC
Are you envisioning a status table on each source per vdb, or a single status table for all of teiid? Each has considerations for table/entry naming/versioning.
Are you suggesting that the scripts execute as dynamic sql or against the source native procedure?
> Add management features to materialization
> ------------------------------------------
>
> Key: TEIID-2584
> URL: https://issues.jboss.org/browse/TEIID-2584
> Project: Teiid
> Issue Type: Feature Request
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
> Fix For: 8.5
>
>
> Currently Teiid supports internal and external materialization features. The internal is managed completely by the Teiid query engine along with the infinispan cache.
> External materialization is completely unmanaged and left out to the user to manage it externally. This goals for this feature are unify the materialization logic for internal and external, such that both are managed similarly irrespective of the type of materialization chosen.
--
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, 5 months
[JBoss JIRA] (TEIID-2620) Add support for array/list indexing in teiid script
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2620?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2620.
-----------------------------------
Resolution: Done
Allowed integral accessors to be used on arrays/lists to get values. Updated the reference to show an example as well. Also fixed an issue with the serialization of the arrayimpl value (which in theory is not yet supported).
> Add support for array/list indexing in teiid script
> ---------------------------------------------------
>
> Key: TEIID-2620
> URL: https://issues.jboss.org/browse/TEIID-2620
> Project: Teiid
> Issue Type: Enhancement
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.4.1, 8.5
>
>
> With Teiid script (the default for objecttable) you currently have to hand array processing over to arraytable rather than directly using arrays in the script.
--
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, 5 months
[JBoss JIRA] (TEIID-2620) Add support for array/list indexing in teiid script
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-2620:
-------------------------------------
Summary: Add support for array/list indexing in teiid script
Key: TEIID-2620
URL: https://issues.jboss.org/browse/TEIID-2620
Project: Teiid
Issue Type: Enhancement
Components: Query Engine
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 8.4.1, 8.5
With Teiid script (the default for objecttable) you currently have to hand array processing over to arraytable rather than directly using arrays in the script.
--
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, 5 months