Comment 3 for bug 655352

I'd lean in favor of not reusing the update header as it seems simplest /
cleanest.

On Thu, Oct 7, 2010 at 1:37 PM, Joe Daly <email address hidden> wrote:

> Im wondering if the best fix for this would be to remove the
> optimization of reusing the update header and having multiple updates in
> the statement. Alternatively the other solution would be to check the
> fields on previous update and compare them to the new update if they are
> equal combine if not create a new statement.
>
> --
> Transaction log blending two distinct UPDATES in a single transaction
> incorrectly
> https://bugs.launchpad.net/bugs/655352
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in A Lightweight SQL Database for Cloud Infrastructure and Web
> Applications: Confirmed
>
> Bug description:
> The transaction log appears to be merging / blending two distinct UPDATES
> (against the same table) within a single transaction with bad results.
>
> >From the test case:
> These two UPDATES -
>
> UPDATE `c` SET `col_int_not_null` = 1 WHERE `col_int` BETWEEN 7 AND 108
> ORDER BY
> `col_bigint`,`col_bigint_key`,`col_bigint_not_null`,`col_bigint_not_null_key`,`col_char_10`,`col_char_1024`,`col_char_1024_key`,`col_char_1024_not_null`,`col_char_1024_not_null_key`,`col_char_10_key`,`col_char_10_not_null`,`col_char_10_not_null_key`,`col_enum`,`col_enum_key`,`col_enum_not_null`,`col_enum_not_null_key`,`col_int`,`col_int_key`,`col_int_not_null`,`col_int_not_null_key`,`col_text`,`col_text_key`,`col_text_not_null`,`col_text_not_null_key`,`pk`
> LIMIT 7 ;
>
> UPDATE `c` SET `col_int_not_null_key` = 10 WHERE
> `col_char_10_not_null_key` >= 'p' ORDER BY
> `col_bigint`,`col_bigint_key`,`col_bigint_not_null`,`col_bigint_not_null_key`,`col_char_10`,`col_char_1024`,`col_char_1024_key`,`col_char_1024_not_null`,`col_char_1024_not_null_key`,`col_char_10_key`,`col_char_10_not_null`,`col_char_10_not_null_key`,`col_enum`,`col_enum_key`,`col_enum_not_null`,`col_enum_not_null_key`,`col_int`,`col_int_key`,`col_int_not_null`,`col_int_not_null_key`,`col_text`,`col_text_key`,`col_text_not_null`,`col_text_not_null_key`,`pk`
> LIMIT 5 ;
>
> End up in the transaction log like this (all changes merged into the first
> update / new values for the second UPDATE are attributed to col_int_not_null
> instead of col_int_not_null_key)
> statement {
> type: UPDATE
> START_TIMESTAMP
> END_TIMESTAMP
> update_header {
> table_metadata {
> schema_name: "test"
> table_name: "c"
> }
> key_field_metadata {
> type: INTEGER
> name: "pk"
> }
> set_field_metadata {
> type: INTEGER
> name: "col_int_not_null"
> }
> }
> update_data {
> segment_id: 1
> end_segment: true
> record {
> key_value: "11"
> after_value: "1"
> is_null: false
> }
> record {
> key_value: "7"
> after_value: "1"
> is_null: false
> }
> record {
> key_value: "13"
> after_value: "1"
> is_null: false
> }
>
> ############# This should be for col_int_not_null_key : (
> ###################################
> record {
> key_value: "3"
> after_value: "10"
> is_null: false
> }
> record {
> key_value: "7"
> after_value: "10"
> is_null: false
> }
> record {
> key_value: "8"
> after_value: "10"
> is_null: false
> }
> record {
> key_value: "9"
> after_value: "10"
> is_null: false
> }
> record {
> key_value: "12"
> after_value: "10"
> is_null: false
> }
> }
> }
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/drizzle/+bug/655352/+subscribe
>