← Back to branch summary

~drizzle-trunk/drizzle/development

« back to all changes in this revision

Viewing changes to drizzled/message/transaction.proto

https://launchpad.net/bugs/588251
doStartTableScan() result not checked.

Add __attribute__((warn_unused_result)) to Cursor::startTableScan()
and by extension init_read_records

then go and fix the places where we weren't checking for errors.

This patch helped by Monty Widenius' patch to MariaDB. Greatly increased
confidence that we either handle the errors correctly or are at least
on par with bugs :)

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? */
511
510
}
512
511
 
513
512
/*
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
}