From: barries
Date: March 31 2001 10:32pm
Subject: Re: Hacking triggers into 2.23.34a?
List-Archive: http://lists.mysql.com/internals/660
Message-Id: <20010331173229.D7007@jester.slaysys.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

On Sat, Mar 31, 2001 at 04:10:43PM +0300, Michael Widenius wrote:
> 
> Sorry for the delay in answering this..

No probs, thanks for looking at it.

> Instead of creating item for all columns, can't you instead let
> the trigger test the columns it's interested in?

Sure.  New patch forthcoming.

> If this is ok, you only have to pass the RowUpdated() function the
> table in question.

Luckily it's known to the trigger (passed in to constructor so it can
pre-calculate things).

<mysqld guts hints snipped; many thanks> 
> To access the new value, you can use the field class.

s/field class/Field instance/ ?

Just checking to make sure I'm not missing something subtle about the
Field class...

> To access the old value, you can create a new field that points at
> this as follows:
> 
> Field old_field= *field;
> old_field.move_field(table->rec_buff_length);

I get this:

   trigger.cc: In method `int PostUpdateTrigger::WatchFieldsUpdated(TABLE *)':
   trigger.cc:87: cannot declare variable `old_field' to be of type `Field'
   trigger.cc:87:   since the following virtual functions are abstract:
   field.h:108:    void Field::sort_string(char *, unsigned int)
   field.h:107:    void Field::make_field(Send_field *)
   field.h:96:     uint Field::size_of() const
   field.h:91:     void Field::sql_type(String &) const
   field.h:79:     int Field::cmp(const char *, const char *)
   field.h:76:     enum enum_field_types Field::type() const
   field.h:65:     enum Item_result Field::result_type() const
   field.h:64:     class String * Field::val_str(String *, String *)
   field.h:63:     longlong Field::val_int()
   field.h:62:     double Field::val_real()
   field.h:60:     void Field::store(long long int)
   field.h:59:     void Field::store(double)
   field.h:58:     void Field::store(const char *, unsigned int)
   trigger.cc:87: cannot allocate an object of type `Field'
   trigger.cc:87:   since type `Field' has abstract virtual functions

When I try that.

How's this instead:

  List_iterator<Field> i(extractFields);
  Field *f;
  List<Field> old_fields ;
  while (f=i++) {
    Field *old_field= f->new_field(table);
    old_field->move_field(table->rec_buff_length);
    old_fields.push_back(old_field);
  }

  return Handler(extractFields,old_fields);

?

> We are have been talking about hiring a new developer, Arnold, to add
> a foreign language API to MySQL.  The current plan is to first
> construct a good API and then create a Python interface for this.
> (People keep telling us that Python is very suited for task like this,
> so we decided to start with a Python interface).

Sounds reasonable.  I'd guess that many people (myself included, of
course :-) would prefer Perl, possibly even a majority.  'course, I just
look at the mod_perl memory consumption and threading issues (now that
Apache 2.0 nears) to see why it's probably not as optimal as Python.

> Arnold has the last month done some research in how to most
> efficiently implement this so and I hope to get some inputs from him
> soon.

Very cool.  It'll give me the excuse I need to dig deeper into Python.
'course, it seems like only Perlers have responded to posts about this
and that we're on the cusp of extending the embedded perls mentioned in
another message.

> Only the source.

"Use the source, Luke." said Monty-wan Kenobi ;-).

> barries> - Assuming that the above approach is tenable, what would be a good way of
> barries>   safely unpacking record[0] and record[1] into reasonable intermediary
> barries>   structures, or should it pass things as List<Field>& instead of
> barries>   List<Item>& for efficiency / ease?
> 
> This would work, but the above approach would be MUCH faster.

Agreed.  I'm now creating a stratified approach to let the coder choose
the appropriate handler level.  Basically, you can overload

   RowUpdated()
   
and do it all yourself, or call AddWatchField( "column%name" ) a few times
in the Trigger constructor and let RowUpdated() call your overloaded

   WatchedFieldsUpdated()
   
only when an interesting ("watched") field changes, or you can also
specify a list of fields to extract by calling AddExtractField( "foo" ) 
in the ctor and allow your overloaded

   Handler(const List<Field>& old_fields, const List<Field>&new_fields)
   
called with already-mapped fields.

This allows you to implement a trigger at a low, medium, or high level
of abstraction (well, as high as Field gets, anyway).

Does that seem reasonable to you?  Current patch at

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

.  I'll gladly send the patch to the list, but I hesitate in case
anyone's one a slow connection.  Not sure what's good ettiquette on this
list.

> We at MySQL AB will of course help by answering any implementation
> questions regarding this.

Very helpful, and many thanks.

- Barrie