-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Query: add translation for string.Compare for Cosmos #20910
Comments
@AndriySvyryd Can't find a duplicate that contains this. |
#16143, but we can keep this one separate |
Hi, I was thinking on translating this function by using string1>string2 comparison in Cosmos, as there is not Compare equivalent function, but we could get the same result by just using > and <. Therefore the basic comparison cold be translated, and also the overloads with starting positions. |
We could indeed translate .NET I agree that we should avoid translating overloads accepting StringComparison, if the only way to implement those would be to use UPPER, negating index use - we've discussed this thoroughly in the context of relational databases, and I think the logic here is the same. Note #25250, which discusses translating Contains, including case-insensitivity, which apparently can be done with Cosmos CONTAINS while maintaining index usage. |
I'm working with an ODATA api over Cosmos DB and ran into this issue when trying to filter with The error I get is:
Packages used: <PackageReference Include="Microsoft.AspNetCore.OData" Version="8.0.11" />
<PackageReference Include="Microsoft.Azure.Cosmos" Version="3.30.1" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Cosmos" Version="6.0.9" /> Using 'ToList' and performing the filtering on the client side works but the should really be done in the database. Is there a workaround for this issue? |
Thanks! So currently there's no way to translate a generic As a partial workaround, i.e. it only supports one predefined filter, I tested adding an ODATA function which can be called with [HttpGet("GetModifiedSince(modified_since={modified_since})")]
public IActionResult GetModifiedSince(string modified_since)
{
var result = CosmosQueryableExtensions.FromSqlRaw(_dbContext.Foo,
"SELECT * FROM c WHERE c.modified_at > {0}", modified_since);
return Ok(result);
} |
No, that's what this issue is about. |
Note: OData $skiptoken uses string.Compare when the token is string based, effectively blocking that feature on Cosmos |
Similarly, expressions with The Cosmos DB .NET SDK for NoSQL includes translation of CompareTo in its LINQ provider. When will Entity Framework Core's Cosmos DB provider translate CompareTo? Also note that a lack of support for CompareTo blocks some higher-level extensions of EF Core when used with the Cosmos DB provider including keyset paging where we construct custom where predicates to execute a query to retrieve the next page (without using offset paging/skip). Are there any workarounds until this is supported in the query translation layer for the Cosmos DB provider? For example, would HasDbFunction/HasTranslation be able to workaround this? |
@clazarr thanks for point that out - yes, I think it makes sense to add CompareTo support to the Cosmos provider along with string.Compare.
Yes, that should be possible. |
both instance and static version
The text was updated successfully, but these errors were encountered: