Implement EF.Functions.JsonExists

[roji]

Based on previous work in #37470 by @kimjaejung96

Closes #31136

[Copilot]

Pull request overview

This PR implements EF.Functions.JsonExists for relational database providers, enabling users to check whether a JSON path exists within JSON data. The implementation supports both scalar string columns containing JSON and complex properties mapped to JSON columns.

Changes:

• Added public API JsonExists extension method to RelationalDbFunctionsExtensions
• Implemented SQLite translation using json_type() function with IS NOT NULL check
• Implemented SQL Server translation using JSON_PATH_EXISTS() function with equality comparison to 1
• Added comprehensive test infrastructure with base tests and provider-specific test implementations

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
src/EFCore.Relational/Extensions/RelationalDbFunctionsExtensions.cs	Adds the public API for JsonExists method that throws on client evaluation
src/EFCore.Sqlite.Core/Query/Internal/SqliteSqlTranslatingExpressionVisitor.cs	Implements SQLite translation using json_type() with IS NOT NULL pattern
src/EFCore.SqlServer/Query/Internal/SqlServerSqlTranslatingExpressionVisitor.cs	Implements SQL Server translation using JSON_PATH_EXISTS() function
test/EFCore.Relational.Specification.Tests/Query/Translations/JsonTranslationsRelationalTestBase.cs	Defines base test suite for JSON translation functions with test data and fixture infrastructure
test/EFCore.Sqlite.FunctionalTests/Query/Translations/JsonTranslationsSqliteTest.cs	SQLite-specific test implementation with SQL assertion verification
test/EFCore.SqlServer.FunctionalTests/Query/Translations/JsonTranslationsSqlServerTest.cs	SQL Server-specific test implementation with version compatibility handling
test/EFCore.SqlServer.FunctionalTests/Query/Associations/ComplexJson/ComplexJsonSqlServerFixture.cs	Minor formatting improvement (adds blank line for consistency)

[AndriySvyryd]

What about owned?

[roji]

The code here should actually cover owned as well, though I didn't do test coverage for that; do we want to actually invest time in developing new features for owned JSON, given the path we're on?

[AndriySvyryd]

do we want to actually invest time in developing new features for owned JSON, given the path we're on?

Yes

[roji]

Maybe we should rediscuss. I also didn't implement partial ExecuteUpdate support for owned JSON in 10, for instance - I thought we were more or less agreed not to invest more time in it.

[AndriySvyryd]

I thought we were more or less agreed not to invest more time in it.

It's certainly not a priority, but if you don't add the functionality, you still need to throw an exception stating that it's not supported for owned instead of a generic translation failure

[roji]

Oh, we throw generic translation failures for bigger things - am just trying to focus our time where it matters more. But if it's important to you I can add a specific exception message.

[AndriySvyryd]

It just seems like adding a test or a new exception here is about the same amount of work.

[roji]

Maybe. I didn't feel like adding a test for an obsolete feature was worth it. If it's that easy I'll do it.