[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:
-------------------------------------
>From pg/oracle trigger tables, they record it is "BEFORE" or "AFTER" as to when they issue the trigger. I know it does not apply to Teiid yet, but I captured it, if Teiid supports those kind of triggers in the future.
> 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, 3 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 is the firing_time column on the triggers table?
> 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, 3 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 resolved TEIID-2640.
-----------------------------------
Resolution: Incomplete Description
Marking as an incomplete description for now. If something comes up in the associated forum post, this will be reopened.
> 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, 3 months
[JBoss JIRA] (TEIID-2641) improve transaction handling in procedures
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2641?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-2641:
----------------------------------
Affects Version/s: 8.2
(was: 7.6)
Except for the first issue (which I'm not quite sure how far back it goes), all of the other issues are due to TEIID-1386, so updating the affects version to 8.2.
> improve transaction handling in procedures
> ------------------------------------------
>
> Key: TEIID-2641
> URL: https://issues.jboss.org/browse/TEIID-2641
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.2
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 8.4.1, 8.5
>
>
> Atomic blocks do not have well-defined handling w.r.t. variable assignments and the implicit return cursor. In both cases the affects are currently non-atomic - the last assignment/cursor is effective even.
> Also exception handling in an atomic block must result in an exception being thrown to guarantee the entire block atomicity.
--
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, 3 months
[JBoss JIRA] (TEIID-2641) improve transaction handling in procedures
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2641?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-2641:
----------------------------------
Fix Version/s: 8.4.1
> improve transaction handling in procedures
> ------------------------------------------
>
> Key: TEIID-2641
> URL: https://issues.jboss.org/browse/TEIID-2641
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 7.6
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 8.4.1, 8.5
>
>
> Atomic blocks do not have well-defined handling w.r.t. variable assignments and the implicit return cursor. In both cases the affects are currently non-atomic - the last assignment/cursor is effective even.
> Also exception handling in an atomic block must result in an exception being thrown to guarantee the entire block atomicity.
--
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, 3 months