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

   Vyššie na [Platon] / phpMyEdit / doc / sgml
Rozdiely pre phpMyEdit/doc/sgml/configuration.general.sgml medzi verziami 1.46 a 1.47


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



Riadok 1 




Riadok 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>




Riadok 518  and without the need to enter them manua




Riadok 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>




Riadok 538  the corresponding operation, or after th




Riadok 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>




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




Riadok 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>




Riadok 700  operation described. All involved trigge




Riadok 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




Riadok 739  to perform database queries for fetching




Riadok 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:


Odstranené z verzie1.46
 


zmenené riadky


 
Pridané vo verzii1.47


















Platon Group <platon@platon.sk> http://platon.sk/
  Vyššie na [Platon] / phpMyEdit / doc / sgml
-verzia 1.46, 2004/11/20 02:24:34
+verzia 1.47, 2004/12/08 16:21:17
 Riadok 1
 Riadok 1
 Riadok 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>
 Riadok 518  and without the need to enter them manua
 Riadok 518  and without the need to enter them manua
 Riadok 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>
-Riadok 538  the corresponding operation, or after th
+Riadok 539  the corresponding operation, or after th
 Riadok 538  the corresponding operation, or after th
 Riadok 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>
-Riadok 583  If 'pre' triggers fail, users are sent b
+Riadok 615  If 'pre' triggers fail, users are sent b
 Riadok 583  If 'pre' triggers fail, users are sent b
 Riadok 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>
-Riadok 700  operation described. All involved trigge
+Riadok 703  operation described. All involved trigge
 Riadok 700  operation described. All involved trigge
 Riadok 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
-Riadok 739  to perform database queries for fetching
+Riadok 743  to perform database queries for fetching
 Riadok 739  to perform database queries for fetching
 Riadok 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:


Odstranené z verzie1.46
 


zmenené riadky


 
Pridané vo verzii1.47
 Legend:


Odstranené z verzie1.46
 


zmenené riadky


 
Pridané vo verzii1.47
-Odstranené z verzie1.46
+Pridané vo verzii1.47


Copyright © 2002-2006 Platon Group Stránka používa redakčný systém Metafox	Na začiatok