Remove undesired exists() conditions from query-to-pipeline conversion #9444
Conversation
|
Summary of ChangesHello @wu-hui, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request refines the Firestore query-to-pipeline conversion process by eliminating undesired Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request correctly removes the undesired exists() conditions from the query-to-pipeline conversion for != and not-in operators. The changes in pipeline-util.ts align the behavior with Firestore's query semantics, and the new integration tests in query_to_pipeline.test.ts effectively verify this. However, I've identified a critical issue where one of the changes could lead to a runtime error for queries without an explicit orderBy clause.
| const existsConditions = query.explicitOrderBy.map(order => | ||
| field(order.field.canonicalString()).exists() | ||
| ); |
There was a problem hiding this comment.
This change to use query.explicitOrderBy is correct for the PR's goal. However, it can result in existsConditions being an empty array, which exposes a bug in the subsequent logic (lines 172-182). When existsConditions is empty, pipeline.where(existsConditions[0]) is called with undefined, causing a runtime error for any query without an explicit orderBy.
To prevent this, please add a check to ensure existsConditions is not empty before attempting to add a where clause.
Here's a suggested fix:
if (existsConditions.length > 0) {
const condition =
existsConditions.length === 1
? existsConditions[0]
: and(
existsConditions[0],
existsConditions[1],
...existsConditions.slice(2)
);
pipeline = pipeline.where(condition);
}There was a problem hiding this comment.
agree. Line 180 below should be else if (existsConditions.length > 0) ...
Size Report 1Affected Products
Test Logs |
Size Analysis Report 1Affected ProductsNo changes between base commit (f044045) and merge commit (27c810d).Test Logs |
MarkDuckworth
left a comment
MarkDuckworth
left a comment
There was a problem hiding this comment.
LGTM with small request for change
| const existsConditions = query.explicitOrderBy.map(order => | ||
| field(order.field.canonicalString()).exists() | ||
| ); |
There was a problem hiding this comment.
agree. Line 180 below should be else if (existsConditions.length > 0) ...
3 participants
No description provided.