Opensource.Platon.SK CVS: phpMyEdit/doc/sgml/configuration.general.sgml - diff

   Up to  [Platon] / phpMyEdit / doc / sgml
Diff for phpMyEdit/doc/sgml/configuration.general.sgml between version 1.46 and 1.47


version 1.46, 2004/11/20 02:24:34
version 1.47, 2004/12/08 16:21:17



Line 1 




Line 1 




 <!-- $Platon: phpMyEdit/doc/sgml/configuration.general.sgml,v 1.45 2004/11/10 17:00:14 nepto Exp $ -->
 <!-- $Platon: phpMyEdit/doc/sgml/configuration.general.sgml,v 1.46 2004/11/20 02:24:34 nepto Exp $ -->


 
 


 <sect1 id="configuration.mysql-options">
 <sect1 id="configuration.mysql-options">


 <title id="configuration.mysql-options.title">Database connection</title>
 <title id="configuration.mysql-options.title">Database connection</title>




Line 518  and without the need to enter them manua




Line 518  and without the need to enter them manua




 
 


 <sect1 id="configuration.triggers">
 <sect1 id="configuration.triggers">


 <title id="configuration.triggers.title">Triggers</title>
 <title id="configuration.triggers.title">Triggers</title>


 
 <bridgehead>Triggers overview</bridgehead>


 <para>
 <para>


 
 


 Triggers are files that are included via <function>include()</function>
 Triggers are files that are included via <function>include()</function>




Line 538  the corresponding operation, or after th




Line 539  the corresponding operation, or after th




 </para>
 </para>


 <para>
 <para>


 
 


 
 For SQL triggers, the operation sequence is this: before, main, after.  If any


 
 operation fails, not only should the next operation(s) not be executed, but


 
 the previous ones are 'rolled back' as if they never happened.  If a database


 
 is not able to do this, it is not 'transaction-safe'.


 
 


 
 </para>


 
 <para>


 
 


 
 Triggers are risky in basic MySQL as there is no native transaction support.  It


 
 is not transaction-safe by default. There are transaction-safe table types in


 
 MySQL that can be conditionally built (see MySQL-Max), but &name; is currently


 
 not set up to support real transactions. What that means is that if an


 
 operation fails, the database may be left in an intermediate and invalid state.


 
 


 
 </para>


 
 <para>


 
 


 
 The programmer must understand and accept these risks prior to using the &name;


 
 triggers mechanism. If the triggers are used, they execute within the namespace


 
 or scope of the &name; class.


 
 


 
 </para>


 
 <para>


 
 


 
 Triggers must return <constant>true</constant> or <constant>false</constant>


 
 to indicate success or failure.


 
 


 
 </para>


 
 <bridgehead>Triggers types</bridgehead>


 
 <para>


 
 


 There are following types of &name; triggers:
 There are following types of &name; triggers:


 
 


 </para>
 </para>




Line 583  If 'pre' triggers fail, users are sent b




Line 615  If 'pre' triggers fail, users are sent b




 trigger fails.
 trigger fails.


 
 


 </para>
 </para>


 <para>
 <bridgehead>Trigger examples</bridgehead>


 
 


 For SQL triggers, the operation sequence is this: before, main, after.  If any
 


 operation fails, not only should the next operation(s) not be executed, but
 


 the previous ones are 'rolled back' as if they never happened.  If a database
 


 is not able to do this, it is not 'transaction-safe'.
 


 
 


 </para>
 


 <para>
 


 
 


 Triggers are risky in basic MySQL as there is no native transaction support.  It
 


 is not transaction-safe by default. There are transaction-safe table types in
 


 MySQL that can be conditionally built (see MySQL-Max), but &name; is currently
 


 not set up to support real transactions. What that means is that if an
 


 operation fails, the database may be left in an intermediate and invalid state.
 


 
 


 </para>
 


 <para>
 


 
 


 The programmer must understand and accept these risks prior to using the &name;
 


 triggers mechanism. If the triggers are used, they execute within the namespace
 


 or scope of the &name; class.
 


 
 


 </para>
 


 <para>
 


 
 


 Triggers must return <constant>true</constant> or <constant>false</constant>
 


 to indicate success or failure.
 


 
 


 </para>
 


 <para>
 <para>


 
 


 <example><title>Select triggers</title>
 <example><title>Select triggers</title>




Line 700  operation described. All involved trigge




Line 703  operation described. All involved trigge




 </itemizedlist>
 </itemizedlist>


 
 


 </para>
 </para>


 
 <bridgehead>Triggers variables</bridgehead>


 <para>
 <para>


 
 


 In every trigger file you have available following usable variables. Some of
 In every trigger file you have available following usable variables. Some of




Line 739  to perform database queries for fetching




Line 743  to perform database queries for fetching




 updates to other database tables.
 updates to other database tables.


 
 


 </para>
 </para>


 
 <bridgehead>Chained triggers</bridgehead>


 
 <para>


 
 


 
 You may set several triggers for the same operation. This allows to isolate


 
 code, to share more easily triggers between multiple calling scripts and to


 
 reuse code produced by another &name; users.


 
 


 
 </para>


 
 <para>


 
 


 
 The order triggers are executed in is important. It is set by the keys of the


 
 chained triggers. As soon as one of the chained trigger fail, the overall


 
 return value is set to <constant>false</constant>, and following triggers are


 
 not executed. If none of chained triggers failed, then the return value is


 
 <constant>true</constant>.


 
 


 
 <example><title>Chained update before triggers</title>


 
 <programlisting><![CDATA[


 
 $opts['triggers']['update']['before'][1] = 'lock.TUA.inc';


 
 $opts['triggers']['update']['before'][0] = 'check.TUB.inc';


 
 ]]></programlisting>


 
 </example>


 
 


 
 </para>


 
 <para>


 
 


 
 In this example, when the user clicks on the <GUIbutton>Save</GUIbutton>


 
 button during editing a record, <filename>check.TUB.inc</filename> will be run


 
 first. If it returns <constant>true</constant>, then


 
 <filename>lock.TUB.inc</filename> will be run as well.  If one of these


 
 triggers fails, update of the database won't be performed, just like if a


 
 simple <varname>['update']['before']</varname> trigger failed. Note that


 
 although the overall return value of 'cancel' triggers does not inluence


 
 &name; behavior, the return value of each chained trigger is important.


 
 


 
 </para>


 </sect1>
 </sect1>


 
 


 <sect1 id="configuration.logging">
 <sect1 id="configuration.logging">









Legend:


Removed from v.1.46
 


changed lines


 
Added in v.1.47


















Platon Group <platon@platon.org> http://platon.org/
  Up to  [Platon] / phpMyEdit / doc / sgml
-version 1.46, 2004/11/20 02:24:34
+version 1.47, 2004/12/08 16:21:17
 Line 1
 Line 1
 Line 1
- <!-- $Platon: phpMyEdit/doc/sgml/configuration.general.sgml,v 1.45 2004/11/10 17:00:14 nepto Exp $ -->
+ <!-- $Platon: phpMyEdit/doc/sgml/configuration.general.sgml,v 1.46 2004/11/20 02:24:34 nepto Exp $ -->
  <sect1 id="configuration.mysql-options">
  <title id="configuration.mysql-options.title">Database connection</title>
 Line 518  and without the need to enter them manua
 Line 518  and without the need to enter them manua
 Line 518  and without the need to enter them manua
  <sect1 id="configuration.triggers">
  <title id="configuration.triggers.title">Triggers</title>
+ <bridgehead>Triggers overview</bridgehead>
  <para>
  Triggers are files that are included via <function>include()</function>
-Line 538  the corresponding operation, or after th
+Line 539  the corresponding operation, or after th
 Line 538  the corresponding operation, or after th
 Line 539  the corresponding operation, or after th
  </para>
  <para>
+ For SQL triggers, the operation sequence is this: before, main, after.  If any
+ operation fails, not only should the next operation(s) not be executed, but
+ the previous ones are 'rolled back' as if they never happened.  If a database
+ is not able to do this, it is not 'transaction-safe'.
+ </para>
+ <para>
+ Triggers are risky in basic MySQL as there is no native transaction support.  It
+ is not transaction-safe by default. There are transaction-safe table types in
+ MySQL that can be conditionally built (see MySQL-Max), but &name; is currently
+ not set up to support real transactions. What that means is that if an
+ operation fails, the database may be left in an intermediate and invalid state.
+ </para>
+ <para>
+ The programmer must understand and accept these risks prior to using the &name;
+ triggers mechanism. If the triggers are used, they execute within the namespace
+ or scope of the &name; class.
+ </para>
+ <para>
+ Triggers must return <constant>true</constant> or <constant>false</constant>
+ to indicate success or failure.
+ </para>
+ <bridgehead>Triggers types</bridgehead>
+ <para>
  There are following types of &name; triggers:
  </para>
-Line 583  If 'pre' triggers fail, users are sent b
+Line 615  If 'pre' triggers fail, users are sent b
 Line 583  If 'pre' triggers fail, users are sent b
 Line 615  If 'pre' triggers fail, users are sent b
  trigger fails.
  </para>
- <para>
+ <bridgehead>Trigger examples</bridgehead>
- For SQL triggers, the operation sequence is this: before, main, after.  If any
- operation fails, not only should the next operation(s) not be executed, but
- the previous ones are 'rolled back' as if they never happened.  If a database
- is not able to do this, it is not 'transaction-safe'.
- </para>
- <para>
- Triggers are risky in basic MySQL as there is no native transaction support.  It
- is not transaction-safe by default. There are transaction-safe table types in
- MySQL that can be conditionally built (see MySQL-Max), but &name; is currently
- not set up to support real transactions. What that means is that if an
- operation fails, the database may be left in an intermediate and invalid state.
- </para>
- <para>
- The programmer must understand and accept these risks prior to using the &name;
- triggers mechanism. If the triggers are used, they execute within the namespace
- or scope of the &name; class.
- </para>
- <para>
- Triggers must return <constant>true</constant> or <constant>false</constant>
- to indicate success or failure.
- </para>
  <para>
  <example><title>Select triggers</title>
-Line 700  operation described. All involved trigge
+Line 703  operation described. All involved trigge
 Line 700  operation described. All involved trigge
 Line 703  operation described. All involved trigge
  </itemizedlist>
  </para>
+ <bridgehead>Triggers variables</bridgehead>
  <para>
  In every trigger file you have available following usable variables. Some of
-Line 739  to perform database queries for fetching
+Line 743  to perform database queries for fetching
 Line 739  to perform database queries for fetching
 Line 743  to perform database queries for fetching
  updates to other database tables.
  </para>
+ <bridgehead>Chained triggers</bridgehead>
+ <para>
+ You may set several triggers for the same operation. This allows to isolate
+ code, to share more easily triggers between multiple calling scripts and to
+ reuse code produced by another &name; users.
+ </para>
+ <para>
+ The order triggers are executed in is important. It is set by the keys of the
+ chained triggers. As soon as one of the chained trigger fail, the overall
+ return value is set to <constant>false</constant>, and following triggers are
+ not executed. If none of chained triggers failed, then the return value is
+ <constant>true</constant>.
+ <example><title>Chained update before triggers</title>
+ <programlisting><![CDATA[
+ $opts['triggers']['update']['before'][1] = 'lock.TUA.inc';
+ $opts['triggers']['update']['before'][0] = 'check.TUB.inc';
+ ]]></programlisting>
+ </example>
+ </para>
+ <para>
+ In this example, when the user clicks on the <GUIbutton>Save</GUIbutton>
+ button during editing a record, <filename>check.TUB.inc</filename> will be run
+ first. If it returns <constant>true</constant>, then
+ <filename>lock.TUB.inc</filename> will be run as well.  If one of these
+ triggers fails, update of the database won't be performed, just like if a
+ simple <varname>['update']['before']</varname> trigger failed. Note that
+ although the overall return value of 'cancel' triggers does not inluence
+ &name; behavior, the return value of each chained trigger is important.
+ </para>
  </sect1>
  <sect1 id="configuration.logging">
 Legend:


Removed from v.1.46
 


changed lines


 
Added in v.1.47
 Legend:


Removed from v.1.46
 


changed lines


 
Added in v.1.47
-Removed from v.1.46
+Added in v.1.47


Copyright © 2002-2006 Platon Group Site powered by Metafox CMS	Go to Top