---

This section details on the original issue you should resolve

<issue_title>Delete.FromTable issue</issue_title>
<issue_description>I have the following in my migration:

Delete.FromTable("RolePermissions").Row(new { PermissionId = RawSql.Insert("(SELECT [Id] FROM [dbo].[Permissions] WHERE [Name] = 'Foo')") });

But since upgrading from 6.2.0 to 7.0.0 it now throws the error:

Exception: An error occurred executing the following sql:
DELETE FROM [dbo].[RolePermissions] WHERE [PermissionId] (SELECT [Id] FROM [dbo].[Permissions] WHERE [Name] = 'Foo')
The error was An expression of non-boolean type specified in a context where a condition is expected, near '('.</issue_description>

<agent_instructions>Look into the breaking change introduced in #1904 - see if there is a way to generalize the behavior of InsertDataExpression, UpdateDataExpression and DeleteDataExpression such that expression generation for all 3 is more consistent across the 3 expression types.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@PhenX Oh, I see the problem, that's a breaking change I did not anticipate when improving RawSql support. That means that anybody using the old supported syntax undergoes this breaking change ...

I see two possible syntaxes for you :

Delete.FromTable("RolePermissions").Row(new { PermissionId = RawSql.Insert("= PermissionId = (SELECT [Id] FROM [dbo].[Permissions] WHERE [Name] = 'Foo')") });

or

Delete.FromTable("RolePermissions").Row("PermissionId = (SELECT [Id] FROM [dbo].[Permissions] WHERE [Name] = 'Foo')");

@PhenX I don't know, it would make a new breaking changge (again) ...

@jzabroski how could we handle it ? Maybe with a configuration ?</comment_new>
<comment_new>@jzabroski
The first answer always has to be to add unit test coverage.

In this case, I am surprised it worked in 6.2.0. Did you confirm? I will probably test it myself in a few hours. </comment_new>
<comment_new>@jzabroski

Do you expect to patch this? To go back and update my migrations across all my sites is likely going to cause a few headaches.

To directly answer your question, if it is a break, yes, I expect to fix it in the upcoming release. This unit test needs updating to capture your usage
https://github.com/fluentmigrator/fluentmigrator/blob/main/test/FluentMigrator.Tests/Integration/MigrationRunnerTests.cs#L2172-L2184</comment_new>
<comment_new>@PhenX
The difference is that before, it used to assume the RawSql contained only what's after the "=", now it needs to contain the operand.</comment_new>
<comment_new>@PhenX
We may need to bring a new "un-breaking" change, in the third syntax of the unit test I guess.</comment_new>
<comment_new>@jzabroski
@PhenX This should be fixable, as he is not relying on the code generating an IN clause. That is something we do not support. I think it can "know" the operand based on whether its a CAR or CDR expression (in Lisp terms). The issue is here basically:

cc22f38#diff-47ff32219b9f01c1320bd7e9dac971767a201a8c36ceb1f7beecbd4aa0e87185L340-R381</comment_new>
<comment_new>@jzabroski
@PhenX Does that help? He is essentially saying InsertDataExpression, DeleteDataExpression and UpdateDataExpression should all have the same behavior with respect to RawSql.Insert, which I think is fair.</comment_new>
<comment_new>@PhenX
One is for a where the other one for a list of values though. But I get why it feels inconsistent </comment_new>
<comment_new>@jzabroski
That is why I think the right solution is to detect whether the expression is inside another object or not. I would need to prototype it myself and cannot right now but I feel like it is possible.</comment_new>