List:Internals« Previous MessageNext Message »
From:Michael Widenius Date:April 1 2001 9:10am
Subject:Re: Hacking triggers into 2.23.34a?
View as plain text  
Hi!

>>>>> "barries" == barries  <barries@stripped> writes:

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

barries> 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?

barries> Sure.  New patch forthcoming.

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

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

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

barries> s/field class/Field instance/ ?

Yes; I mean that you can use the functions that the field class provides
for the field instances to solve this nicely.

barries> Just checking to make sure I'm not missing something subtle
barries> 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);

barries> I get this:

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

Sorry, I forgot about that :(

barries> When I try that.

barries> How's this instead:

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

barries> return Handler(extractFields,old_fields);

barries> ?

Yes this should work ok as long as you don't do that in a loop!
The reason is that each new_field allocates space which will not be
freed until the SQL statement is completed.

>> We are have been talking about hiring a new developer, Arnulf, 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).

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

Perl would probably be the second language we would look at including,
after Python is done.

>> Arnulf 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.

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

I am a Perl user myself (never done Python before), so I have the same
excuse :)

>> Only the source.

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

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

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

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

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

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

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

barries> Does that seem reasonable to you?  Current patch at

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

Yes, it sounds very good.

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

I think the above is good until you are satisfied with the patch.
After you are 'done', if you don't mind, I could put this in our
Patches section on the web page to make it easily accessible.

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

barries> Very helpful, and many thanks.

barries> - Barrie

Regards,
Monty
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