← Back to branch summary

~drizzle-trunk/drizzle/development

« back to all changes in this revision

Viewing changes to drizzled/message/transaction.proto

  • Committer: kalebral at gmail
  • Date: 2010-12-18 04:43:40 UTC
  • mto: This revision was merged to the branch mainline in revision 2010.
  • Revision ID: kalebral@gmail.com-20101218044340-og61cyjogqwp0k0o
update Copyright strings to a more common format to help with creating the master debian copyright file

Show diffs side-by-side

added added

removed removed

Lines of Context:
drizzled/message/transaction.proto
575
575
  optional CreateTableStatement create_table_statement = 15;
576
576
  optional AlterTableStatement alter_table_statement = 16;
577
577
  optional DropTableStatement drop_table_statement = 17;  
578
 
  optional SetVariableStatement set_variable_statement = 18;
 
578
  optional SetVariableStatement set_variable_statement = 18;  
579
579
}
580
580
 
581
581
/*
592
592
  required TransactionContext transaction_context = 1;
593
593
  repeated Statement statement = 2;
594
594
  optional Event event = 3;
595
 
 
596
 
  /*
597
 
   * A single transaction in the database can possibly be represented with
598
 
   * multiple protobuf Transaction messages if the message grows too large.
599
 
   * This can happen if you have a bulk transaction, or a single statement
600
 
   * affecting a very large number of rows, or just a large transaction with
601
 
   * many statements/changes.
602
 
   *
603
 
   * For the first two examples, it is likely that the Statement sub-message
604
 
   * itself will get segmented, causing another Transaction message to be
605
 
   * created to hold the rest of the Statement's row changes. In these cases,
606
 
   * it is enough to look at the segment information stored in the Statement
607
 
   * message.
608
 
   *
609
 
   * For the last example, the Statement sub-messages may or may not be
610
 
   * segmented, but we could still need to split the Statements up into
611
 
   * multiple Transaction messages to keep the Transaction message size from
612
 
   * growing too large. In this case, the segment information in the Statement
613
 
   * submessages is not helpful if the Statement isn't segmented. We need this
614
 
   * information in the Transaction message itself.
615
 
   *
616
 
   * These values should be set appropriately whether or not the Statement
617
 
   * sub-messages are segmented.
618
 
   */
619
 
  optional uint32 segment_id = 4; /* Segment number of the Transaction msg */
620
 
  optional bool end_segment = 5;  /* FALSE if Transaction msg is split into multiples */
621
595
}