[JBoss JIRA] (TEIID-2931) Perform equi-join full outer joins in a streaming manner
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2931?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-2931:
----------------------------------
Fix Version/s: 7.7.9
> Perform equi-join full outer joins in a streaming manner
> --------------------------------------------------------
>
> Key: TEIID-2931
> URL: https://issues.jboss.org/browse/TEIID-2931
> Project: Teiid
> Issue Type: Enhancement
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 7.7.9, 8.7.1, 8.8
>
>
> A pass to compute the right outer matches is only needed when there is non-equi join criteria, since we'll already have determined the right outer values that fail to match the equi-join predicates on the first pass. Note that second passes are limited only to the match regions, but we don't have effective buffering logic for that so we just fully buffer each side.
--
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
10 years, 8 months
[JBoss JIRA] (TEIID-2640) Field with NULL value is replaced by a non-NULL field during modify
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2640?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-2640.
---------------------------------
> Field with NULL value is replaced by a non-NULL field during modify
> -------------------------------------------------------------------
>
> Key: TEIID-2640
> URL: https://issues.jboss.org/browse/TEIID-2640
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.4
> Environment: Java application running on Mainframe
> Reporter: Sai Gujja
> Assignee: Steven Hawkins
> Labels: Date, NULL, VARCHAR
>
> We have a java application running on Mainframe that uses TEIID. We used the Database Explorer plugin as well to reproduce the error.
> We were trying to update two fields, of which one had a value that we were trying to remove and adding a value to the other one. Let's say the fields are CONSID and EXPDATE. CONSID is a vachar that accepts a one letter word, such as 's','a' etc. EXPDATE is a date field. CONSID had a value in it already before we started our modify function. So our modification included removing the value for CONSID(making it NULL) and adding a date for EXPDATE. So the update Query we sent looked like:
> Execute UPDATE tssadmingrp=acids,host=de30_de29,o=cai,c=us SET EXPDATE = {d '2013-12-12'}, CONSID = NULL WHERE acf2admingrp=lids,host=xe42_cia,o=ca,c=us?SUBTREE_SCOPE.DN = '"tssacid=TSSACID,tssadmingrp=acids,host=de30_de29,o=cai,c=us"'
> We use a LDAP translator to send these modify queries to LDAP server. The update query seemed right, but the query that is sent over to LDAP was wrong. The values that were being sent to LDAP were same for CONSID and EXPDATE (both of them had date values in them). Since LDAP doesn't recognize date value in CONSID, it failed.
> This is where we don't understand what is going wrong between the update query being generated and that is sent to LDAP. Can you please advice us?
> Thank you.
--
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
10 years, 8 months
[JBoss JIRA] (TEIID-2688) NPE determining dependent join cost
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2688?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-2688.
---------------------------------
> NPE determining dependent join cost
> -----------------------------------
>
> Key: TEIID-2688
> URL: https://issues.jboss.org/browse/TEIID-2688
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 7.4
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.6, 7.7.8
>
>
> Given that the initial node in the cost determination is not a select node if it is "pushed" to a point where the criteria is assumed to exist, then an NPE is thrown:
> java.lang.NullPointerException
> at org.teiid.query.optimizer.relational.rules.JoinUtil.replaceWithNullValues(JoinUtil.java:186)
> at org.teiid.query.optimizer.relational.rules.JoinUtil.isNullDependent(JoinUtil.java:141)
> at org.teiid.query.optimizer.relational.rules.JoinUtil.optimizeJoinType(JoinUtil.java:106)
> at org.teiid.query.optimizer.relational.rules.RulePushSelectCriteria.examinePath(RulePushSelectCriteria.java:356)
> at org.teiid.query.optimizer.relational.rules.NewCalculateCostUtil.determineTargets(NewCalculateCostUtil.java:1294)
> at org.teiid.query.optimizer.relational.rules.NewCalculateCostUtil.computeCostForDepJoin(NewCalculateCostUtil.java:1155)
> at org.teiid.query.optimizer.relational.rules.JoinRegion.getDepJoinCost(JoinRegion.java:373)
> at org.teiid.query.optimizer.relational.rules.JoinRegion.scoreRegion(JoinRegion.java:316)
> at org.teiid.query.optimizer.relational.rules.RulePlanJoins.findBestJoinOrder(RulePlanJoins.java:571)
> at org.teiid.query.optimizer.relational.rules.RulePlanJoins.execute(RulePlanJoins.java:173)
> at org.teiid.query.optimizer.relational.RelationalPlanner.executeRules(RelationalPlanner.java:525)
> at org.teiid.query.optimizer.relational.RelationalPlanner.optimize(RelationalPlanner.java:212)
> at org.teiid.query.optimizer.QueryOptimizer.optimizePlan(QueryOptimizer.java:195)
> This will occur if the prospective dependent join for example is above an outer join such that we need to check whether pushing the criteria would alter the meaning of the join.
--
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
10 years, 8 months
[JBoss JIRA] (TEIID-2783) ModeShape query isn't retaining quotes defined for column in NIS
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2783?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-2783.
---------------------------------
> ModeShape query isn't retaining quotes defined for column in NIS
> ----------------------------------------------------------------
>
> Key: TEIID-2783
> URL: https://issues.jboss.org/browse/TEIID-2783
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.4.1
> Reporter: Van Halbert
> Assignee: Van Halbert
> Attachments: ModeShape.vdb
>
>
> Issuing query:
> SELECT jcr_name FROM nt_base AS children WHERE JCR_ISCHILDNODE(children.jcr_path, '/pathtoparent')
> produces exception:
> Caused by: javax.jcr.query.InvalidQueryException: The JCR-SQL2 query "SELECT g_0.jcr:name FROM "nt:base" AS g_0 WHERE ISCHILDNODE(g_0.jcr:path, '/pathtoparent')" is not well-formed: Expecting "FROM" but found ":" at line 1, column 15: SELECT g_0.jcr ===>> :name FROM "nt:base"
> at org.modeshape.jcr.JcrQueryManager.createQuery(JcrQueryManager.java:146)
> at org.modeshape.jcr.JcrQueryManager.createQuery(JcrQueryManager.java:101)
--
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
10 years, 8 months
[JBoss JIRA] (TEIID-2798) Add creation of view when exposing metadata via Object translator
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2798?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-2798.
---------------------------------
> Add creation of view when exposing metadata via Object translator
> -----------------------------------------------------------------
>
> Key: TEIID-2798
> URL: https://issues.jboss.org/browse/TEIID-2798
> Project: Teiid
> Issue Type: Enhancement
> Components: Misc. Connectors
> Affects Versions: 8.4.1
> Reporter: Van Halbert
> Assignee: Van Halbert
>
> When the metadata is exposed for the java object via the Object translator, a view should also be created using a template similar to:
> SELECT
> t.{pkKeyField}, o.{colname}, o.{colname}
> FROM Order
> {ObjectSourceTable} as T,
> OBJECTTABLE('x' PASSING T.{ObjectTypeName}Object as x COLUMNS
> {colname} {type} 'teiid_row.{colname}', ….) as o
> where
> {pkKeyField} is the primary key column to the cache
> {ObjectSourceTable} is the source table imported above
> {ObjectTypeName} is the column added in {ObjectSourceTable} to reference the cache object
> {colname} is the name of the columns that have “get” methods, see the {ObjectSourceTable} for columns to use
> {type} is the data type for this column
--
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
10 years, 8 months
[JBoss JIRA] (TEIID-2795) TTL Snapshot Refresh doesn't fully reload Internal MV if the user query contains LIMIT
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2795?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-2795.
---------------------------------
> TTL Snapshot Refresh doesn't fully reload Internal MV if the user query contains LIMIT
> --------------------------------------------------------------------------------------
>
> Key: TEIID-2795
> URL: https://issues.jboss.org/browse/TEIID-2795
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 7.7.8
> Reporter: Debbie Steigner
> Assignee: Johnathon Lee
> Fix For: 7.7.9
>
> Attachments: TEIID-2795.patch
>
>
> using the cache hint to automatically trigger a full snapshot refresh after a specified time to live (TTL)[1]. The TTL works but if the user query that is run contains a LIMIT clause the refresh load uses the LIMIT and doesn't completely load the internal MV and fails load.
> Sequence of events
> 1) Execute the query to initiate the internal MV load
> 2) After caching, issue the same query but with limit of 10,000 to test it is hitting the cache
> 3) Wait for 5 minutes for TTL to expire
> 4) Re-issue the same query with limit of 10,000 and i can see the state change to reloading but once the query has finished fetching 10,000 from data source it terminates and the MV state changed to failed_load. I would have expected the MV to continue to load to rehydrate the cache and the query should be fetching the data from the stale cache. But this is not the case ...
> [1]https://access.redhat.com/site/documentation/en-US/JBoss_Enterprise_Dat...
--
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
10 years, 8 months