ExecuteUpdate SetProperty generated UPDATE statement order

[ChristianSteu]

I run into some to my knowledge undocumented behavior while using ExecuteUpdate and using database values for setting new values and I'm not sure if this is the correct place or if it would be more fitting directed directly at efcore.

As an example going off the EF Core 7 examples I want to update the Title to a new value and appending the old title to the Content.

This isn't to complicated and in EF it looks like this:

await context.Posts
    .ExecuteUpdateAsync(s => s
        .SetProperty(b => b.Content, b => b.Content + " ( Title was " + b.Title  + ")"))
        .SetProperty(b => b.Title, b => "New Title");

Problem is that MySQL deviates from the SQL Standard and basically performs one value update after another, so depending on the order of the statements the result is different.

The above gets translated to this:

      UPDATE `posts` AS `p`
      SET `p`.`title` = 'New Title',
          `p`.`content` = CONCAT(CONCAT(CONCAT(`p`.`content`, ' ( Title was '), `p`.`title`), ')')

which does not produce the intended result, since it appends ( Title was New title) no matter the old title (because the updated title value is used while setting the content). If I switch the SetProperty-Calls, then the resulting SQL has a different order inside the SET and it works as intended.

It seems like whatever builds the final statement uses a stack to translate the several SetProperty-Calls to the SET parts, so the order in the SQL is exactly backwards from the order used in the code.

To me that doesn't feel intuitive, so the question is: is this intended behavior (I couldn't find it explicitly documented on EfCore, although the example on the page also swaps the order. But from a SQL-Standard perspective it is also nothing that should be relevant, so I wouldn't expect EfCore to define it either way.) or something that can/might change (or should the current behavior be labeled as a bug?)

[yukozh]

The translation looks good to me. What is your expected translation?

[ChristianSteu]

Thanks for the answer :-)

The issue is the (to me) unexpected order (which does matter in MySQL). Just from looking at the code I would expect the SQL order to be the same as in the code (So UPDATE `posts` AS `p` SET `p`.`content` = ..., `p`.`title` = ... in this case).

I'm not sure if that is an "undocumented specification" or a bug/leaking implementation detail. To me it looks like the latter, that's why I'm asking about.