fix sql syntax in DatabaseCacheRepository

[idseefeld]

Prerequisites

All test have to be successful.
Find details in issue #19954

[github-actions]

Hi there @idseefeld, thank you for this contribution! 👍

While we wait for one of the Core Collaborators team to have a look at your work, we wanted to let you know about that we have a checklist for some of the things we will consider during review:

• It's clear what problem this is solving, there's a connected issue or a description of what the changes do and how to test them
• The automated tests all pass (see "Checks" tab on this PR)
• The level of security for this contribution is the same or improved
• The level of performance for this contribution is the same or improved
• Avoids creating breaking changes; note that behavioral changes might also be perceived as breaking
• If this is a new feature, Umbraco HQ provided guidance on the implementation beforehand
• 💡 The contribution looks original and the contributor is presumably allowed to share it

Don't worry if you got something wrong. We like to think of a pull request as the start of a conversation, we're happy to provide guidance on improving your contribution.

If you realize that you might want to make some changes then you can do that by adding new commits to the branch you created for this work and pushing new commits. They should then automatically show up as updates to this pull request.

Thanks, from your friendly Umbraco GitHub bot 🤖 🙂

[Copilot]

Pull Request Overview

This PR fixes SQL syntax issues in the DatabaseCacheRepository.cs file by replacing raw SQL strings with strongly-typed SQL builder methods and improving SQL syntax compatibility across different database providers.

Key Changes

• Replaced raw SQL DELETE statements with strongly-typed SQL builder pattern
• Updated column name quoting to use proper SQL syntax provider methods
• Consolidated duplicate deletion logic into a single reusable method

[AndyButland]

Thanks for this @idseefeld. I'm mostly happy with the clean-up apart from a few nit-picky comments. The main concern I have is the complexity introduced by by-passing the InsertOrUpdateAsync method, so please see my inline comment on that.

[AndyButland]

Would it be better to define a parameter in Where and pass that parameter as the second argument to Execute? Maybe it doesn't really matter, so just flagging for you to consider. If you do update, there are further instances of this in the proposed changes.

[idseefeld]

No I don't agree. I think this is the proper way to avoid raw partial sql statments.
Previously the raw sql was:

DELETE FROM cmsContentNu
WHERE cmsContentNu.nodeId IN (
    SELECT id FROM umbracoNode
    JOIN {Constants.DatabaseSchema.Tables.Content} ON {Constants.DatabaseSchema.Tables.Content}.nodeId=umbracoNode.id
    WHERE umbracoNode.nodeObjectType = @objType
    AND {Constants.DatabaseSchema.Tables.Content}.contentTypeId IN (@ctypes)

which had to be extended with the SqlSyntax.GetQuoted... methods like:

DELETE FROM {SqlSyntax.GetQuotedTableName("cmsContentNu")}
WHERE {SqlSyntax.GetQuotedTableName("cmsContentNu")}.{SqlSyntax.GetQuotedColumnName("nodeId")} IN (
    SELECT id FROM {SqlSyntax.GetQuotedTableName("umbracoNode")}
    JOIN {SqlSyntax.GetQuotedTableName(Constants.DatabaseSchema.Tables.Content)} ON {SqlSyntax.GetQuotedTableName(Constants.DatabaseSchema.Tables.Content)}.{SqlSyntax.GetQuotedColumnName("nodeId")}={SqlSyntax.GetQuotedTableName("umbracoNode")}.id
    WHERE {SqlSyntax.GetQuotedTableName("umbracoNode")}.{SqlSyntax.GetQuotedColumnName("nodeObjectType")} = @objType
    AND {SqlSyntax.GetQuotedTableName(Constants.DatabaseSchema.Tables.Content)}.{SqlSyntax.GetQuotedColumnName("contentTypeId")} IN (@ctypes)

Actually I haven't found a solution for mixing Sql<ISqlContext>() objects with named parameters / arguments.
Somewhere I have seen methods for this kind of subqueries to build a sql string snippet where the actual parameters where replaced by arguments in an Excecute call. In that approach I have indeed extended the raw sql, because I could not think of another solution without extensive refactoring.