Add session filter support for DML statement #1931
Conversation
To be squashed
And make it more explicit it does not require an actual cast
|
I have fixed the I have also added some multi-table filtered DML tests: they fail. The insert case is failing only in the case of a filter on the joined table. That is maybe a DML insert limitation, and maybe that case should be just ignored. The update and delete case suffer the same trouble than #1921: filter parameters are not processed and stay in the SQL. This happens for the SQL used for populating the temporary tables used for multi-table update/delete. |
| @@ -102,7 +102,7 @@ public async Task DmlDeleteAsync(bool filtered) | |||
|
|
|||
| [TestCase(null)] | |||
| [TestCase("NameFilter")] | |||
| [TestCase("OtherNameFilter")] | |||
| [TestCase("OtherNameFilter", IgnoreReason = "Not supported")] | |||
There was a problem hiding this comment.
Currently the insert statement does not have a multi table executer as update/delete have.
There was a problem hiding this comment.
Yes, but the filter does not require a multi-table handling (which is meant to insert/update/delete many tables). It requires a join instead in the select clause.
Having the filter on the joined table silently ignored while it seems correctly taken into account for updates/deletes is a bit troublesome. (Granted, the test only check the count of entities considered updated by the statement. It does not check in the database that only expected entities have been updated. It should likely be checked too.)
There was a problem hiding this comment.
And in fact, it is supported, and it works. That is the test which is bugged...
There was a problem hiding this comment.
Thanks for correcting me, I overlooked the query and mistakenly assumed that the issue was with the lack of the multi executor.
There was a problem hiding this comment.
That's me who wrote the bugged test in the first place, it was my mistake indeed.
| @@ -82,6 +82,7 @@ public whereClause | |||
| ; | |||
|
|
|||
| whereClauseExpr | |||
| // 6.0 TODO: Remove "(SQL_TOKEN) => conditionList" | |||
| : (SQL_TOKEN) => conditionList | |||
There was a problem hiding this comment.
Is not used anymore as AddDiscriminatorWhereFragment is now deprecated.
fredericDelaporte
changed the title
hazzik
dismissed stale reviews from fredericDelaporte and themself
via
daddf1a
|
Is it possible breaking change? |
|
Yes, it is a possible breaking change for |
Fixes #1921
Fixes #803
Possible breaking change:
updateanddeletestatements will now take into account any enabled filter on the entities they update or delete, while previously they were ignoring them. (insertstatements will also take them into account, but previously they were failing instead of ignoring enabled filters.)