[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:
---------------------------------------
Do you have an update on this or can this be resolved for now?
> 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
[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:
---------------------------------------
Can we also remove or change the property form of MATERIALIZED_TABLE (which can be determined from the materialized_views table) and the UPDATE_COUNT? The fewer "med" properties we natively rely on the better.
For the triggers table, see the system tables in oracle/pg. You'd likely have columns:
schema, table, trigger body, trigger type (INSTEAD OF), triggering event (INSERT/UPDATE/DELETE), status (ENABLED/DISABLED)
common stuff - which we currently don't track as we aren't creating a proper metadata record:
name, description, uid
Yes, the refresh procedure looks about right (With an atomic block and dynamic sql for the delete/select that should do the trick). We should allow a variation of that to work against internal materialized views as well. We can leave off manipulations to the cache hint then.
Another open issue seems to be that the engine does not have a built-in way to react to the mat view status. If the status is something other than loaded/valid, then we should likely have a configurable outcome - ignore, error, wait?, refesh?, etc.
> 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
[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:
----------------------------------
Issue Type: Bug (was: Quality Risk)
Priority: Critical (was: Major)
> 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.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, 4 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:
----------------------------------
Summary: improve transaction handling in procedures (was: qimprove transaction handling in procedures)
Description:
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.
was:
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.
Also exception handling in an atomic block must result in an exception being thrown to guarantee the entire block atomicity.
> improve transaction handling in procedures
> ------------------------------------------
>
> Key: TEIID-2641
> URL: https://issues.jboss.org/browse/TEIID-2641
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine
> Affects Versions: 7.6
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 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, 4 months
[JBoss JIRA] (TEIID-2641) qimprove transaction handling in procedures
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-2641:
-------------------------------------
Summary: qimprove transaction handling in procedures
Key: TEIID-2641
URL: https://issues.jboss.org/browse/TEIID-2641
Project: Teiid
Issue Type: Quality Risk
Components: Query Engine
Affects Versions: 7.6
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 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.
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, 4 months