[ https://jira.jboss.org/browse/TEIID-1351?page=com.atlassian.jira.plugin.s... ] Steven Hawkins updated TEIID-1351: ---------------------------------- Description: While we hardened the usage in 7.2, translate criteria has too many implied restrictions to reliably perform the update/delete the user query is specifying. It would be better to rely on better default handling (especially pass-through) TEIID-1349 and to remove the current restrictions on virtual update, such as requiring scalar set clause values and no subquery evaluation TEIID-1267. This change should not remove the possibility of using TRANSLATE CRITERIA/CREATE PROCEDURE, as it will not be removed until Teiid 8 or later. Beyond the default handling, one possible construct is to provide the user with an cursor that contains the update (or delete) set with the corresponding updated values. Then leave it up to the user to iterate over the change set and process the changes. One drawback with this approach is that it may be hard to decipher from the view output rows how to apply the updates to constituent tables when the view transformation is a set or join and branch descriminators or additional primary keys are not projected. Of course those situations were already difficult to handle with translate criteria. This will require coordinated designer changes. was: While we hardened the usage in 7.2, translate criteria has too many implied restrictions to reliably perform the update/delete the user query is specifying. It would be better to rely on better default handling (especially pass-through) TEIID-1349 and to remove the current restrictions on virtual update, such as requiring scalar set clause values and no subquery evaluation TEIID-1276. This change should not remove the possibility of using TRANSLATE CRITERIA/CREATE PROCEDURE, as it will not be removed until Teiid 8 or later. Beyond the default handling, one possible construct is to provide the user with an cursor that contains the update (or delete) set with the corresponding updated values. Then leave it up to the user to iterate over the change set and process the changes. One drawback with this approach is that it may be hard to decipher from the view output rows how to apply the updates to constituent tables when the view transformation is a set or join and branch descriminators or additional primary keys are not projected. Of course those situations were already difficult to handle with translate criteria. This will require coordinated designer changes. Affects: [Documentation (Ref Guide, User Guide, etc.), Compatibility/Configuration, Release Notes] (was: [Release Notes, Compatibility/Configuration]) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/TEIID-1351?page=com.atlassian.jira.plugin.s... ] Steven Hawkins commented on TEIID-1351: --------------------------------------- The initial approach that I'm favoring is to add support for something like instead of trigger actions (fairly standard functionality), which will initially support row-by-row updates rather than the changeset described above. So rather than entering an update procedure of the form: CREATE PROCEDURE BEGIN ... END The sql would instead look like: FOR EACH ROW BEGIN ... END The procedure block would execute for each updated row and supply NEW/OLD variable groups to reference the changing values. I don't think that we will initially need support for the referencing clause to change the names of the new/old variables, but it could be added without much effort. The engine would still allow for the old procedure form an behave according to the old rules. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1351?page=com.atlassian.jira.plugin... ] Steven Hawkins closed TEIID-1351. --------------------------------- -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira