[teiid-commits] teiid SVN: r2761 - in trunk: documentation/reference/src/main/docbook/en-US/content and 1 other directory.
teiid-commits at lists.jboss.org
teiid-commits at lists.jboss.org
Mon Dec 6 21:13:53 EST 2010
Author: shawkins
Date: 2010-12-06 21:13:52 -0500 (Mon, 06 Dec 2010)
New Revision: 2761
Modified:
trunk/build/kits/jboss-container/teiid-releasenotes.html
trunk/documentation/reference/src/main/docbook/en-US/content/procedures.xml
trunk/documentation/reference/src/main/docbook/en-US/content/updatable_views.xml
Log:
TEIID-1351 adding documentation for the new update procedures
Modified: trunk/build/kits/jboss-container/teiid-releasenotes.html
===================================================================
--- trunk/build/kits/jboss-container/teiid-releasenotes.html 2010-12-06 18:06:30 UTC (rev 2760)
+++ trunk/build/kits/jboss-container/teiid-releasenotes.html 2010-12-07 02:13:52 UTC (rev 2761)
@@ -27,7 +27,11 @@
<H2><A NAME="Highlights"></A>Highlights</H2>
<UL>
<LI><B>Subquery Optimization</B> - added rewrite to INNER JOIN for applicable WHERE clause subqueries. Also added cost based SEMI and ANTI-SEMI join handling for applicable non-pushed WHERE and HAVING subqueries.
- <LI><B>Updatable Views</B> - added support to perform simple pass-through and more complicated updates through views by default.
+ <LI><B>Updatable Views</B>
+ <UL>
+ <LI>Added support to perform simple pass-through and more complicated updates through views by default.
+ <LI>Added support for "FOR EACH ROW" update procedure handling (similar to INSTEAD OF triggers in other DBMS's), which should be used instead of the deprecated TRANSLATE criteria approach.
+ </UL>
<LI><B>UDF</B> - new API objects added to teiid-api to support user defined functions that are capable of pushdown to source.
</UL>
Modified: trunk/documentation/reference/src/main/docbook/en-US/content/procedures.xml
===================================================================
--- trunk/documentation/reference/src/main/docbook/en-US/content/procedures.xml 2010-12-06 18:06:30 UTC (rev 2760)
+++ trunk/documentation/reference/src/main/docbook/en-US/content/procedures.xml 2010-12-07 02:13:52 UTC (rev 2761)
@@ -420,200 +420,6 @@
through result sets, use loops, and use conditional logic.
</para>
<section>
- <title>Update Procedure Definition</title>
- <para>
- Usage:
- <synopsis label="Usage" >CREATE PROCEDURE
-BEGIN
- ...
-END</synopsis>
- </para>
- <para>The CREATE PROCEDURE line demarcates the beginning of
- the procedure. The BEGIN and END keywords are used to denote block
- boundaries. Within the body of the procedure, any valid <link linkend="procedure_language">statement</link> may be used.
- </para>
- </section>
- <section>
- <title>Special Variables</title>
- <para>You can use a number of special variables when defining your update procedure.</para>
- <section id="input_variables">
- <title>INPUT Variables</title>
- <para>Every attribute in the view whose UPDATE and INSERT transformations you are defining has an equivalent variable named INPUTS.<column_name></para>
- <para>When an INSERT or an UPDATE command is executed against the view, these variables are initialized to the values in the INSERT VALUES clause or the UPDATE SET clause respectively.</para>
- <para>In an UPDATE procedure, the default value of these variables, if they are not set by the command, is null. In an INSERT procedure, the default value of these variables is the default value of the virtual table attributes, based on their defined types. See <link linkend="changing_variables">CHANGING Variables</link> for distinguishing defaults from passed values.</para>
- <warning>
- <para>In prior release of Teiid INPUT was also accepted as the quailifer for an input variable. As of Teidd 7, INPUT is a reserved word, so INPUTS is the preferred qualifier.</para>
- </warning>
- </section>
- <section id="changing_variables">
- <title>CHANGING Variables</title>
- <para>Similar to INPUT Variables, every attribute in the view whose UPDATE and INSERT transformations you are defining has an equivalent variable named CHANGING.<column_name></para>
- <para>When an INSERT or an UPDATE command is executed against the view, these variables are initialized to <literal>true</literal> or <literal>false</literal> depending on whether the INPUT variable was set by the command.</para>
- <para>For example, for a view with columns A, B, C:</para>
- <informaltable>
- <tgroup cols="2">
- <thead>
- <row>
- <entry>If User Executes...</entry>
- <entry>Then...</entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry><code>INSERT INTO VT (A, B) VALUES (0, 1)</code></entry>
- <entry>CHANGING.A = true, CHANGING.B = true, CHANGING.C = false</entry>
- </row>
- <row>
- <entry><code>UPDATE VT SET C = 2</code></entry>
- <entry>CHANGING.A = false, CHANGING.B = false, CHANGING.C = true</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
- </section>
- <section id="rowsupdated_variable">
- <title>ROWS_UPDATED Variable</title>
- <para> Teiid returns the value of the integer VARIABLES.ROWS_UPDATED variable as a response to an update command executed against
- the view. Your procedure must set the value that returns
- when an application executes an update command against the view,
- which triggers invocation of the update procedure. For
- example, if an UPDATE command is issued that affects 5 records, the
- ROWS_UPDATED should be set appropriately so that the user will
- receive '5' for the count of records affected.</para>
- <example>
- <title>Sample Usage</title>
- <programlisting language="SQL"><![CDATA[...
-UPDATE FOO SET X = 1 WHERE TRANSLATE CRITERIA;
-VARIABLES.ROWS_UPDATED = VARIABLES.ROWCOUNT;
-...]]></programlisting>
- </example>
- </section>
- </section>
- <section>
- <title>Update Procedure Command Criteria</title>
- <para> You can use a number of special SQL clauses when defining
- UPDATE or DELETE procedures. These make it easier to do variable
- substitutions in WHERE clauses or to check on the change state of
- variables without using a lot of conditional logic.</para>
- <section>
- <title>HAS CRITERIA</title>
- <para>You can use the HAS CRITERIA clause to check whether the user’s command has a particular kind of criteria on a particular set of attributes. This clause evaluates to either true or false. You can use it anywhere you can use a criteria within a procedure.</para>
- <para>
- Usage:
- <synopsis>HAS [criteria operator] CRITERIA [ON (column list)]</synopsis>
- </para>
- <itemizedlist>
- <para>Syntax Rules</para>
- <listitem>
- <para>The criteria operator, can be one of =, <, >, <=, >=, <>, LIKE, IS NULL, or IN.
- </para>
- </listitem>
- <listitem>
- <para>If the ON clause is present, HAS CRITERIA will return true only if criteria was present on all of the specified columns.
- </para>
- </listitem>
- <listitem>
- <para>The columns in a HAS CRITERIA ON clause always refer to view columns.
- </para>
- </listitem>
- </itemizedlist>
- <para>Some samples of the HAS CRITERIA clause:</para>
- <informaltable>
- <tgroup cols="2">
- <thead>
- <row>
- <entry>SQL</entry>
- <entry>Result</entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry><code>HAS CRITERIA</code></entry>
- <entry>Checks simply whether there was any criteria at all.</entry>
- </row>
- <row>
- <entry><code>HAS CRITERIA ON (column1, column2)</code></entry>
- <entry>Checks whether the criteria uses column1 and column2.</entry>
- </row>
- <row>
- <entry><code>HAS = CRITERIA ON (column1)</code></entry>
- <entry>Checks whether the criteria has a comparison criteria with = operator.</entry>
- </row>
- <row>
- <entry><code>HAS LIKE CRITERIA</code></entry>
- <entry>Checks whether the criteria has a match criteria using LIKE.</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
- <para>The HAS CRITERIA predicate is most commonly used in
- an IF clause, to determine if the user issued a particular form of
- command and to respond appropriately.</para>
- </section>
- <section>
- <title>TRANSLATE CRITERIA</title>
- <warning><para>TRANSLATE CRITERIA has been deprecated. An alternative approach to update procedures will be introduced in a subsequent version.</para></warning>
- <para>You can use the TRANSLATE CRITERIA clause to convert the criteria from the user application’s SQL command into the form required to interact with the target source or view tables. The TRANSLATE CRITERIA statement uses the SELECT transformation to infer the column mapping. This clause evaluates to a translated criteria that is evaluated in the context of a command.
- You can use these mappings either to replace the default mappings generated from the SELECT transformation or to specify a reverse expression when a virtual column is defined by an expression.</para>
- <para>
- Usage:
- <synopsis>TRANSLATE [criteria operator] CRITERIA [ON (column list)] [WITH (mapping list)]</synopsis>
- </para>
- <para>If there is no user criteria, then the translated criteria is always treated as TRUE.</para>
- <itemizedlist>
- <para>Syntax Rules</para>
- <listitem>
- <para>The criteria operator, can be one of =, <, >, <=, >=, <>, LIKE, IS NULL, or IN.
- </para>
- </listitem>
- <listitem>
- <para>If the ON clause is present, TRANSLATE CRITERIA will only form criteria using the specified columns.
- </para>
- </listitem>
- <listitem>
- <para>The columns in a TRANSLATE CRITERIA ON clause always refer to view columns.
- </para>
- </listitem>
- <listitem>
- <para>The WITH clause always has items with form <elem> = <expression> where the left hand side must refer to a view column.
- </para>
- </listitem>
- <listitem>
- <para>If the WITH clause or a specific mapping is not specified, then a mapping is created based on the SELECT clause of the SELECT transformation (the view column gets mapped to expression in SELECT clause at same position).
- </para>
- </listitem>
- </itemizedlist>
- <para>Some samples of TRANSLATE CRITERIA:</para>
- <informaltable>
- <tgroup cols="2">
- <colspec colwidth="1*"/>
- <colspec colwidth="1*"/>
- <thead>
- <row>
- <entry>SQL</entry>
- <entry>Result</entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry><code>TRANSLATE CRITERIA</code></entry>
- <entry>Translates any user criteria using the default mappings.</entry>
- </row>
- <row>
- <entry>TRANSLATE CRITERIA WITH (column1 = 'A', column2 = INPUTS.column2 + 2)</entry>
- <entry>Translates any criteria with some additional mappings: column1 is always mapped to 'A' and column2 is mapped to the incoming column2 value + 2.</entry>
- </row>
- <row>
- <entry><code>TRANSLATE = CRITERIA ON (column1)</code></entry>
- <entry>Translates only criteria that have = comparison operator and involve column1.</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
- <note><para>If a specific predicate type or column set is specified by TRANSALATE CRITERIA, but the user criteria has predicates that do not match, then an exception will be thrown.</para></note>
- </section>
- </section>
- <section>
<title>Update Procedure Processing</title>
<orderedlist>
<listitem>
@@ -633,7 +439,7 @@
</para>
</listitem>
<listitem>
- <para>Commands, as described in the procedure, as issued to the individual physical data sources or other views.
+ <para>Commands, as described in the procedure, are issued to the individual physical data sources or other views.
</para>
</listitem>
<listitem>
@@ -642,5 +448,287 @@
</listitem>
</orderedlist>
</section>
+ <section>
+ <title>For Each Row</title>
+ <para>A FOR EACH ROW procedure will evaluate its block for each row of the view affected by the update statement.
+ For UPDATE and DELETE statements this will be every row that passes the WHERE condition. For INSERT statements there will be 1 new row for each set of values from the VALUES or query expression.
+ The rows updated is reported as this number regardless of the affect of the underlying procedure logic.</para>
+ <section>
+ <title>Definition</title>
+ <para>
+ Usage:
+ <synopsis label="Usage" >FOR EACH ROW
+ BEGIN
+ ...
+ END</synopsis>
+ </para>
+ <para>The BEGIN and END keywords are used to denote block
+ boundaries. Within the body of the procedure, any valid <link linkend="procedure_language">statement</link> may be used.
+ </para>
+ </section>
+ <section>
+ <title>Special Variables</title>
+ <para>You can use a number of special variables when defining your update procedure.</para>
+ <section id="new_variables">
+ <title>NEW Variables</title>
+ <para>Every attribute in the view whose UPDATE and INSERT transformations you are defining has an equivalent variable named NEW.<column_name></para>
+ <para>When an INSERT or an UPDATE command is executed against the view, these variables are initialized to the values in the INSERT VALUES clause or the UPDATE SET clause respectively.</para>
+ <para>In an UPDATE procedure, the default value of these variables, if they are not set by the command, is the old value. In an INSERT procedure, the default value of these variables is the default value of the virtual table attributes. See CHANGING Variables for distinguishing defaults from passed values.</para>
+ </section>
+ <section id="old_variables">
+ <title>OLD Variables</title>
+ <para>Every attribute in the view whose UPDATE and DELETE transformations you are defining has an equivalent variable named OLD.<column_name></para>
+ <para>When a DELETE or UPDATE command is executed against the view, these variables are initialized to the current values of the row being deleted or updated respectively.</para>
+ </section>
+ <section id="changing_variables">
+ <title>CHANGING Variables</title>
+ <para>Every attribute in the view whose UPDATE and INSERT transformations you are defining has an equivalent variable named CHANGING.<column_name></para>
+ <para>When an INSERT or an UPDATE command is executed against the view, these variables are initialized to <literal>true</literal> or <literal>false</literal> depending on whether the INPUT variable was set by the command.
+ A CHANGING variable is commonly used to differentiate between a default insert value and one specified in the user query.</para>
+ <para>For example, for a view with columns A, B, C:</para>
+ <informaltable>
+ <tgroup cols="2">
+ <thead>
+ <row>
+ <entry>If User Executes...</entry>
+ <entry>Then...</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry><code>INSERT INTO VT (A, B) VALUES (0, 1)</code></entry>
+ <entry>CHANGING.A = true, CHANGING.B = true, CHANGING.C = false</entry>
+ </row>
+ <row>
+ <entry><code>UPDATE VT SET C = 2</code></entry>
+ <entry>CHANGING.A = false, CHANGING.B = false, CHANGING.C = true</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </informaltable>
+ </section>
+ </section>
+ <section>
+ <title>Examples</title>
+ <para>For example, for a view with columns A, B, C:</para>
+ <example>
+ <title>Sample DELETE Procedure</title>
+ <programlisting language="SQL"><![CDATA[FOR EACH ROW
+BEGIN
+ DELETE FROM X WHERE Y = OLD.A;
+ DELETE FROM Z WHERE Y = OLD.A; // cascade the delete
+END]]></programlisting>
+ </example>
+ <example>
+ <title>Sample UPDATE Procedure</title>
+ <programlisting language="SQL"><![CDATA[FOR EACH ROW
+BEGIN
+ IF (CHANGING.B)
+ BEGIN
+ UPDATE Z SET Y = NEW.B WHERE Y = OLD.B;
+ END
+END]]></programlisting>
+ </example>
+ </section>
+ </section>
+ <section>
+ <title>Create Procedure</title>
+ <para>Update procedures defined by "CREATE PROCEDURE ..." have been deprecated.
+ The TRANSLATE CRITERIA mechanism and associated logic is typically not adequite to correctly define an updatable view.</para>
+ <section>
+ <title>Definition</title>
+ <para>
+ Usage:
+ <synopsis label="Usage" >CREATE PROCEDURE
+ BEGIN
+ ...
+ END</synopsis>
+ </para>
+ <para>The CREATE PROCEDURE line demarcates the beginning of
+ the procedure. The BEGIN and END keywords are used to denote block
+ boundaries. Within the body of the procedure, any valid <link linkend="procedure_language">statement</link> may be used.
+ </para>
+ </section>
+ <section>
+ <title>Special Variables</title>
+ <para>You can use a number of special variables when defining your update procedure.</para>
+ <section id="input_variables">
+ <title>INPUT Variables</title>
+ <para>Every attribute in the view whose UPDATE and INSERT transformations you are defining has an equivalent variable named INPUTS.<column_name></para>
+ <para>When an INSERT or an UPDATE command is executed against the view, these variables are initialized to the values in the INSERT VALUES clause or the UPDATE SET clause respectively.</para>
+ <para>In an UPDATE procedure, the default value of these variables, if they are not set by the command, is null. In an INSERT procedure, the default value of these variables is the default value of the virtual table attributes, based on their defined types. See CHANGING Variables for distinguishing defaults from passed values.</para>
+ <warning>
+ <para>In prior release of Teiid INPUT was also accepted as the quailifer for an input variable. As of Teidd 7, INPUT is a reserved word, so INPUTS is the preferred qualifier.</para>
+ </warning>
+ </section>
+ <section>
+ <title>CHANGING Variables</title>
+ <para>Similar to INPUT Variables, every attribute in the view whose UPDATE and INSERT transformations you are defining has an equivalent variable named CHANGING.<column_name></para>
+ <para>When an INSERT or an UPDATE command is executed against the view, these variables are initialized to <literal>true</literal> or <literal>false</literal> depending on whether the INPUT variable was set by the command.</para>
+ <para>For example, for a view with columns A, B, C:</para>
+ <informaltable>
+ <tgroup cols="2">
+ <thead>
+ <row>
+ <entry>If User Executes...</entry>
+ <entry>Then...</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry><code>INSERT INTO VT (A, B) VALUES (0, 1)</code></entry>
+ <entry>CHANGING.A = true, CHANGING.B = true, CHANGING.C = false</entry>
+ </row>
+ <row>
+ <entry><code>UPDATE VT SET C = 2</code></entry>
+ <entry>CHANGING.A = false, CHANGING.B = false, CHANGING.C = true</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </informaltable>
+ </section>
+ <section id="rowsupdated_variable">
+ <title>ROWS_UPDATED Variable</title>
+ <para> Teiid returns the value of the integer VARIABLES.ROWS_UPDATED variable as a response to an update command executed against
+ the view. Your procedure must set the value that returns
+ when an application executes an update command against the view,
+ which triggers invocation of the update procedure. For
+ example, if an UPDATE command is issued that affects 5 records, the
+ ROWS_UPDATED should be set appropriately so that the user will
+ receive '5' for the count of records affected.</para>
+ <example>
+ <title>Sample Usage</title>
+ <programlisting language="SQL"><![CDATA[...
+ UPDATE FOO SET X = 1 WHERE TRANSLATE CRITERIA;
+ VARIABLES.ROWS_UPDATED = VARIABLES.ROWCOUNT;
+ ...]]></programlisting>
+ </example>
+ </section>
+ </section>
+ <section>
+ <title>Update Procedure Command Criteria</title>
+ <para> You can use a number of special SQL clauses when defining
+ UPDATE or DELETE procedures. These make it easier to do variable
+ substitutions in WHERE clauses or to check on the change state of
+ variables without using a lot of conditional logic.</para>
+ <section>
+ <title>HAS CRITERIA</title>
+ <para>You can use the HAS CRITERIA clause to check whether the user’s command has a particular kind of criteria on a particular set of attributes. This clause evaluates to either true or false. You can use it anywhere you can use a criteria within a procedure.</para>
+ <para>
+ Usage:
+ <synopsis>HAS [criteria operator] CRITERIA [ON (column list)]</synopsis>
+ </para>
+ <itemizedlist>
+ <para>Syntax Rules</para>
+ <listitem>
+ <para>The criteria operator, can be one of =, <, >, <=, >=, <>, LIKE, IS NULL, or IN.
+ </para>
+ </listitem>
+ <listitem>
+ <para>If the ON clause is present, HAS CRITERIA will return true only if criteria was present on all of the specified columns.
+ </para>
+ </listitem>
+ <listitem>
+ <para>The columns in a HAS CRITERIA ON clause always refer to view columns.
+ </para>
+ </listitem>
+ </itemizedlist>
+ <para>Some samples of the HAS CRITERIA clause:</para>
+ <informaltable>
+ <tgroup cols="2">
+ <thead>
+ <row>
+ <entry>SQL</entry>
+ <entry>Result</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry><code>HAS CRITERIA</code></entry>
+ <entry>Checks simply whether there was any criteria at all.</entry>
+ </row>
+ <row>
+ <entry><code>HAS CRITERIA ON (column1, column2)</code></entry>
+ <entry>Checks whether the criteria uses column1 and column2.</entry>
+ </row>
+ <row>
+ <entry><code>HAS = CRITERIA ON (column1)</code></entry>
+ <entry>Checks whether the criteria has a comparison criteria with = operator.</entry>
+ </row>
+ <row>
+ <entry><code>HAS LIKE CRITERIA</code></entry>
+ <entry>Checks whether the criteria has a match criteria using LIKE.</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </informaltable>
+ <para>The HAS CRITERIA predicate is most commonly used in
+ an IF clause, to determine if the user issued a particular form of
+ command and to respond appropriately.</para>
+ </section>
+ <section>
+ <title>TRANSLATE CRITERIA</title>
+ <warning><para>TRANSLATE CRITERIA. An alternative approach to update procedures will be introduced in a subsequent version.</para></warning>
+ <para>You can use the TRANSLATE CRITERIA clause to convert the criteria from the user application’s SQL command into the form required to interact with the target source or view tables. The TRANSLATE CRITERIA statement uses the SELECT transformation to infer the column mapping. This clause evaluates to a translated criteria that is evaluated in the context of a command.
+ You can use these mappings either to replace the default mappings generated from the SELECT transformation or to specify a reverse expression when a virtual column is defined by an expression.</para>
+ <para>
+ Usage:
+ <synopsis>TRANSLATE [criteria operator] CRITERIA [ON (column list)] [WITH (mapping list)]</synopsis>
+ </para>
+ <para>If there is no user criteria, then the translated criteria is always treated as TRUE.</para>
+ <itemizedlist>
+ <para>Syntax Rules</para>
+ <listitem>
+ <para>The criteria operator, can be one of =, <, >, <=, >=, <>, LIKE, IS NULL, or IN.
+ </para>
+ </listitem>
+ <listitem>
+ <para>If the ON clause is present, TRANSLATE CRITERIA will only form criteria using the specified columns.
+ </para>
+ </listitem>
+ <listitem>
+ <para>The columns in a TRANSLATE CRITERIA ON clause always refer to view columns.
+ </para>
+ </listitem>
+ <listitem>
+ <para>The WITH clause always has items with form <elem> = <expression> where the left hand side must refer to a view column.
+ </para>
+ </listitem>
+ <listitem>
+ <para>If the WITH clause or a specific mapping is not specified, then a mapping is created based on the SELECT clause of the SELECT transformation (the view column gets mapped to expression in SELECT clause at same position).
+ </para>
+ </listitem>
+ </itemizedlist>
+ <para>Some samples of TRANSLATE CRITERIA:</para>
+ <informaltable>
+ <tgroup cols="2">
+ <colspec colwidth="1*"/>
+ <colspec colwidth="1*"/>
+ <thead>
+ <row>
+ <entry>SQL</entry>
+ <entry>Result</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry><code>TRANSLATE CRITERIA</code></entry>
+ <entry>Translates any user criteria using the default mappings.</entry>
+ </row>
+ <row>
+ <entry>TRANSLATE CRITERIA WITH (column1 = 'A', column2 = INPUTS.column2 + 2)</entry>
+ <entry>Translates any criteria with some additional mappings: column1 is always mapped to 'A' and column2 is mapped to the incoming column2 value + 2.</entry>
+ </row>
+ <row>
+ <entry><code>TRANSLATE = CRITERIA ON (column1)</code></entry>
+ <entry>Translates only criteria that have = comparison operator and involve column1.</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </informaltable>
+ <note><para>If a specific predicate type or column set is specified by TRANSALATE CRITERIA, but the user criteria has predicates that do not match, then an exception will be thrown.</para></note>
+ </section>
+ </section>
+ </section>
</section>
</chapter>
\ No newline at end of file
Modified: trunk/documentation/reference/src/main/docbook/en-US/content/updatable_views.xml
===================================================================
--- trunk/documentation/reference/src/main/docbook/en-US/content/updatable_views.xml 2010-12-06 18:06:30 UTC (rev 2760)
+++ trunk/documentation/reference/src/main/docbook/en-US/content/updatable_views.xml 2010-12-07 02:13:52 UTC (rev 2761)
@@ -13,7 +13,7 @@
<itemizedlist>
<listitem>
- <para>A set operation (INTERSECT, EXCEPT, UNION, UNION ALL)</para>
+ <para>A set operation (INTERSECT, EXCEPT, UNION).</para>
</listitem>
<listitem>
<para>SELECT DISTINCT</para>
@@ -26,6 +26,9 @@
</listitem>
</itemizedlist>
+ <para>A UNION ALL can define an inherently updatable view only if each of the UNION branches is itself inherently updatable.
+ A view defined by a UNION ALL though does not support inherent INSERTs.</para>
+
<para>Any view column that is not mapped directly to a column is not updatable and cannot be targeted by an UPDATE set
clause or be an INSERT column.</para>
More information about the teiid-commits
mailing list