List:Internals« Previous MessageNext Message »
From:barries Date:March 30 2001 10:46pm
Subject:Re: Hacking triggers into 2.23.34a?
View as plain text  
On Thu, Mar 29, 2001 at 02:42:45PM -0500, barries wrote:
> 
> Unless somebody steps forward with an existing implementation or shoots
> down the approach/suggests a better one, I'll probably start on the
> trigger classes early next week.

I lied, here's a patch against a FreeBSD ports collection version of
3.23.34a that implements an update trigger without passing in before &
after row values:

   http://slaysys.com/src/diff.txt

It's creating the triggers based on a table in trigger.cc like:

   static struct st_trigger_def {
     const char *db_name;
     const char *table_name;
     Trigger *(*factory )( TABLE *table );
   } sql_triggers[] = {
      // For now, triggers fire in in reverse declaration order.
      { "t%st", "f%o", t::NewTrigger },
      {  "bar", "foo", t::NewTrigger },
   };

Here's some output from the mysqld's console (indented further)
intermingled with commands from a mysql session (indented less):

   mysql> describe foo ;
   +-------+---------+------+-----+---------+-------+
   | Field | Type    | Null | Key | Default | Extra |
   +-------+---------+------+-----+---------+-------+
   | a     | int(11) | YES  |     | NULL    |       |
   | b     | int(11) | YES  |     | NULL    |       |
   +-------+---------+------+-----+---------+-------+
   2 rows in set (0.00 sec)

      sql/mysqld: ready for connections

   mysql> update foo set a=not a  ;
   Query OK, 2 rows affected (0.01 sec)
   Rows matched: 2  Changed: 2  Warnings: 0

      Added update trigger
      new t
      t fired
      t fired

   mysql> flush tables ;
   Query OK, 0 rows affected (0.01 sec)

      delete t

   mysql> update foo set a=not a  ;
   Query OK, 2 rows affected (0.01 sec)
   Rows matched: 2  Changed: 2  Warnings: 0

      Added update trigger
      new t
      t fired
      t fired

Any clues as to how to take a table and get it's record[0] and record[1]
out into List<Item>?  I suspect that I only need to do the "before"
values this way, as the "after" values should be present in the fields
passed in.

I'd also appreciate any other feedback about the patch you can muster.

I think I've missed at least one of the places table is closed; when I
interrupt mysqld from the shell (^C in my environment), it seems to not
delete the triggers.  Where are tables closed when SIGINT happens?  I
know, I know, break out gdb :-).  But if I find that one, I'll not be
confident I haven't missed other spots, so if somebody can enlighten
me...?

- Barrie
Thread
Hacking triggers into 2.23.34a?barries29 Mar
  • Re: Hacking triggers into 2.23.34a?elble29 Mar
    • Re: Hacking triggers into 2.23.34a?barries29 Mar
      • Re: Hacking triggers into 2.23.34a?elble29 Mar
    • Re: Hacking triggers into 2.23.34a?Jeremy D . Zawodny29 Mar
      • Re: Hacking triggers into 2.23.34a?elble29 Mar
        • Re: Hacking triggers into 2.23.34a?barries29 Mar
          • Re: Hacking triggers into 2.23.34a?Sasha Pachev30 Mar
          • Re: Hacking triggers into 2.23.34a?barries30 Mar
            • Re: Hacking triggers into 2.23.34a?Michael Widenius31 Mar
        • Re: Hacking triggers into 2.23.34a?Sasha Pachev30 Mar
  • Re: Hacking triggers into 2.23.34a?Antony T Curtis30 Mar
  • Hacking triggers into 2.23.34a?Michael Widenius31 Mar
    • Re: Hacking triggers into 2.23.34a?barries31 Mar
      • Re: Hacking triggers into 2.23.34a?Michael Widenius1 Apr
        • Re: Hacking triggers into 2.23.34a?barries1 Apr
          • Re: Hacking triggers into 2.23.34a?barries1 Apr
            • Re: Hacking triggers into 2.23.34a?Michael Widenius1 Apr
              • Re: Hacking triggers into 2.23.34a?barries2 Apr
                • Re: Hacking triggers into 2.23.34a?Michael Widenius2 Apr
          • Re: Hacking triggers into 2.23.34a?Michael Widenius1 Apr
  • SQL92?Antony T Curtis2 Apr