August 2013 - teiid-issues - Jboss List Archives

[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: ------------------------------------- Will this work? {code} create procedure refreshMatView(viewName, criteria) AS BEGIN mv = getMV($viewName) delete from $mv where $criteria; select * into $mv from (loadscript) AS X where $criteria END {code} for above, I will have the proper transitions of status in the "matview status" table. Since I was using select transformation when load script is not provided, this information is needed now. Will move Transformations to Triggers, and move from extension properties to proper column names like {code} create table Triggers ( schema string; table string; type string; -- valid values (SELECT, INSERT, UPDATE, DELETE, INSTEAD OF INSERT, INSTEAD OF UPDATE, INSTEAD OF DELETE) sql_stmt string; ); {code} > 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 > Labels: Beta3 > 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, 4 months

1
0
0 / 0

[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: --------------------------------------- A simple update approach would look something like a nocache merge (rather than a select, which would presumably return the rows). Given the limitation of our merge (which doesn't process row differences), we could instead use a refresh procedure like the above that identifies the table and the condition that identifies the affected rows (which would enable the update to work against tables without primary keys as well) and use dynamic sql to process the delete/insert. I also think the transformations table still needs some work or to be removed. Our notion of an insert/update/delete transformation is non-standard - typically these would be present under a triggers table. Associating the metadata with extension property keys also makes it more difficult to use. > 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 > Labels: Beta3 > 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, 4 months

1
0
0 / 0

[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: ------------------------------------- I have read through both the approaches, seems like dirty flag is improvement on the other technique. I have to say, I did not quite understand the need to invalidating the cache entries first then only refreshing them at time of selection. Other than performance reasons I think the first one of updating single row is sufficient atleast for our needs. Where it follows the pattern {code} create procedure refreshRow(id) AS BEGIN delete from matview where id = $id; select * into matview from mv_original where id = $id; END {code} and whole thing was based on creating triggers on all the tables involved in the view creation. In Teiid, this becomes multi-dimensional problem, where we need triggers on other views/tables in Teiid and on physical source tables. Since there is no good answer, to start with I am fine with extending semantics of nocache hint. The "partial load" script I mentioned is similar, where I was saying user provides the query that updates the mv table. At the same time we can also provide the above single row refresh method. > 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 > Labels: Beta3 > 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, 4 months

1
0
0 / 0

[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 commented on TEIID-2640: --------------------------------------- Ah so this is more of question for the dev forum, rather than an issue at this point. You'll have to post your extension or detail the method where the modification is being made for us to understand what is happening. > 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

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2639) Internally generated and user submitted anonymous blocks can't access temp tables from the surrounding scope

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2639?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-2639: ---------------------------------- Fix Version/s: 8.4.1 > Internally generated and user submitted anonymous blocks can't access temp tables from the surrounding scope > ------------------------------------------------------------------------------------------------------------ > > Key: TEIID-2639 > URL: https://issues.jboss.org/browse/TEIID-2639 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 7.7 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.4.1, 8.5 > > > While the blocks are resolved against the surrounding scope, when executed the procedure plan shields them from seeing the higher level scopes just as when a real procedure is executed. This results in temporary table 'temp' not found exceptions, for example with a non-simple view v and the delete: > delete from v where e2 = (select max(e2) from temp as z where e3 = z.e3) -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2640) Field with NULL value is replaced by a non-NULL field during modify

by Sai Gujja (JIRA)

[ https://issues.jboss.org/browse/TEIID-2640?page=com.atlassian.jira.plugin... ] Sai Gujja commented on TEIID-2640: ---------------------------------- We are using an extended translator for LDAP. Our translator generates an LDAP query based off of the UPDATE statement, but the query we see in LDAP logs have Date value in both the fields, CONSID and EXPDATE. I don't see anything in the server.log other than the EXECUTE UPDATE query: 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=TSSWOLF,tssadmingrp=acids,host=de30_de29,o=cai,c=us"' We are using Database Explorer to send the above query that will remove CONSID value and add EXPDATE value. > 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

11 years, 4 months

1
0
0 / 0

[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 commented on TEIID-2640: --------------------------------------- > 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? It's not clear to me the exact sequence of events here. Are you using just the built-in translator or something that has been extended? Where exactly is the removal of the set happening and how? > 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

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2640) Field with NULL value is replaced by a non-NULL field during modify

by Sai Gujja (JIRA)

Sai Gujja created TEIID-2640: -------------------------------- Summary: 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 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

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2035) DeleteDataSource method on Admin API does not completely delete the Connection Factory

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-2035?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-2035: ------------------------------------------------ Rostislav Svoboda <rsvoboda(a)redhat.com> made a comment on [bug 985576|https://bugzilla.redhat.com/show_bug.cgi?id=985576] Stefano, will you work on this BZ or will you close this BZ based on Comment 13 and Comment 14 ? > DeleteDataSource method on Admin API does not completely delete the Connection Factory > -------------------------------------------------------------------------------------- > > Key: TEIID-2035 > URL: https://issues.jboss.org/browse/TEIID-2035 > Project: Teiid > Issue Type: Bug > Components: AdminApi > Affects Versions: 8.0 > Reporter: Ramesh Reddy > Assignee: Ramesh Reddy > Labels: CR1 > Fix For: 8.4.1, 8.5 > > > ConnectionFactory requires a two step creation process > 1) create the resource-adaptor section > 2) connection factory section > The delete is removing the (2) and not (1). Thus any subsequent creates using the same name fails. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2639) Internally generated and user submitted anonymous blocks can't access temp tables from the surrounding scope

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-2639?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated TEIID-2639: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1000623 > Internally generated and user submitted anonymous blocks can't access temp tables from the surrounding scope > ------------------------------------------------------------------------------------------------------------ > > Key: TEIID-2639 > URL: https://issues.jboss.org/browse/TEIID-2639 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 7.7 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.5 > > > While the blocks are resolved against the surrounding scope, when executed the procedure plan shields them from seeing the higher level scopes just as when a real procedure is executed. This results in temporary table 'temp' not found exceptions, for example with a non-simple view v and the delete: > delete from v where e2 = (select max(e2) from temp as z where e3 = z.e3) -- 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, 4 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues August 2013