~drizzle-trunk/drizzle/development

« back to all changes in this revision

Viewing changes to drizzled/cursor.cc

  • Committer: Andrew Hutchings
  • Date: 2010-09-08 19:03:09 UTC
  • mfrom: (1750 staging)
  • mto: (1750.1.1 build)
  • mto: This revision was merged to the branch mainline in revision 1751.
  • Revision ID: andrew@linuxjedi.co.uk-20100908190309-mya1nu7xvo1fpvk8
Merge trunk into branch

Show diffs side-by-side

added added

removed removed

Lines of Context:
1327
1327
     * called.  If it fails, then a call to deleteRecord()
1328
1328
     * is called, followed by a repeat of the original
1329
1329
     * call to insertRecord().  So, log_row_for_replication
1330
 
     * could be called either once or twice for a REPLACE
 
1330
     * could be called multiple times for a REPLACE
1331
1331
     * statement.  The below looks at the values of before_record
1332
1332
     * and after_record to determine which call to this
1333
1333
     * function is for the delete or the insert, since NULL
1340
1340
     */
1341
1341
    if (after_record == NULL)
1342
1342
    {
1343
 
      transaction_services.deleteRecord(session, table);
 
1343
      /*
 
1344
       * The storage engine is passed the record in table->record[1]
 
1345
       * as the row to delete (this is the conflicting row), so
 
1346
       * we need to notify TransactionService to use that row.
 
1347
       */
 
1348
      transaction_services.deleteRecord(session, table, true);
1344
1349
      /* 
1345
1350
       * We set the "current" statement message to NULL.  This triggers
1346
1351
       * the replication services component to generate a new statement
1358
1363
    break;
1359
1364
  case SQLCOM_INSERT:
1360
1365
  case SQLCOM_INSERT_SELECT:
 
1366
  case SQLCOM_LOAD:
1361
1367
    /*
1362
1368
     * The else block below represents an 
1363
1369
     * INSERT ... ON DUPLICATE KEY UPDATE that