← Back to branch summary

~drizzle-trunk/drizzle/development

« back to all changes in this revision

Viewing changes to drizzled/message/transaction.proto

  • Committer: Brian Aker
  • Date: 2011-01-18 07:21:16 UTC
  • mfrom: (2079.3.3 session-fix)
  • Revision ID: brian@tangent.org-20110118072116-nuflltzguzhq9rgg
Merge in update so that test-run.pl runs all of test/suite and fix for
create table like and FK.

Show diffs side-by-side

added added

removed removed

Lines of Context:
drizzled/message/transaction.proto
507
507
message DropTableStatement
508
508
{
509
509
  required TableMetadata table_metadata = 1; /* Minimal metadata about the table to be dropped */
 
510
  optional bool if_exists_clause = 2; /* Did the user specify an IF EXISTS clause? */
510
511
}
511
512
 
512
513
/*
574
575
  optional CreateTableStatement create_table_statement = 15;
575
576
  optional AlterTableStatement alter_table_statement = 16;
576
577
  optional DropTableStatement drop_table_statement = 17;  
577
 
  optional SetVariableStatement set_variable_statement = 18;  
 
578
  optional SetVariableStatement set_variable_statement = 18;
578
579
}
579
580
 
580
581
/*
591
592
  required TransactionContext transaction_context = 1;
592
593
  repeated Statement statement = 2;
593
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 */
594
621
}