← Back to branch summary

~drizzle-trunk/drizzle/development

« back to all changes in this revision

Viewing changes to drizzled/message/transaction.proto

  • Committer: Lee Bieber
  • Date: 2010-11-07 19:34:48 UTC
  • mfrom: (1910.1.2 build)
  • Revision ID: kalebral@gmail.com-20101107193448-64kdu912qej354sh
Merge Stewart - including adapting and expanding the "differences from mysql" page from the wiki.
Merge Stewart - fix bug 668143: drizzleslap with --commit runs second iteration data load in a transaction

Show diffs side-by-side

added added

removed removed

Lines of Context:
drizzled/message/transaction.proto
547
547
    CREATE_TABLE = 8; /* A CREATE TABLE statement */
548
548
    ALTER_TABLE = 9; /* An ALTER TABLE statement */
549
549
    DROP_TABLE = 10; /* A DROP TABLE statement */
550
 
    ROLLBACK_STATEMENT = 11; /* ROLLBACK current statement */
551
550
    SET_VARIABLE = 98; /* A SET statement */
552
551
    RAW_SQL = 99; /* A raw SQL statement */
553
552
  }
575
574
  optional CreateTableStatement create_table_statement = 15;
576
575
  optional AlterTableStatement alter_table_statement = 16;
577
576
  optional DropTableStatement drop_table_statement = 17;  
578
 
  optional SetVariableStatement set_variable_statement = 18;
 
577
  optional SetVariableStatement set_variable_statement = 18;  
579
578
}
580
579
 
581
580
/*
592
591
  required TransactionContext transaction_context = 1;
593
592
  repeated Statement statement = 2;
594
593
  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
594
}