feat(firestore): Support for Firestore Pipeline APIs#18013
feat(firestore): Support for Firestore Pipeline APIs#18013SelaseKay wants to merge 27 commits intofeat/firestore-pipelinesfrom
Conversation
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. |
f4d9cca to
9374586
Compare
9374586 to
b4089d8
Compare
…ultiple orderings
…tional binary and unary operations
… query capabilities
…mproved expression handling
* use builtin GITHUB_TOKEN instead of explicit secret * add explicit permission
…7988) Support for reading entity ids from paths in response extension Hardening SQLite to use transactions for edits Setup schema versioning to handle future schema updates. Handle edge cases - multi-dimensional arrays, mixed type arrays, scalar arrays
* feat: bump Firebase JS SDK to 12.9.0 * chore: fix formatting * chore: revert JS SDK bump
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request introduces support for Firestore Pipeline APIs across Android, iOS, and Web platforms. The changes include new Dart classes for building and executing pipelines, platform-specific implementations to parse and run these pipelines, and updates to the pigeon files for communication. The implementation looks solid, with new classes for expressions, stages, and results. I've left a few comments on the Android native implementation regarding null handling and code consistency. Additionally, there are significant refactoring changes in the firebase_data_connect package related to its caching mechanism, which seem to be out of scope for this PR but have been reviewed and appear correct.
Note: Security Review did not run due to the size of the PR.
| if (pipelineResult.getCreateTime() != null) { | ||
| resultBuilder.setCreateTime(pipelineResult.getCreateTime().toDate().getTime()); | ||
| } else { | ||
| resultBuilder.setCreateTime(0L); | ||
| } | ||
|
|
||
| if (pipelineResult.getUpdateTime() != null) { | ||
| resultBuilder.setUpdateTime(pipelineResult.getUpdateTime().toDate().getTime()); | ||
| } else { | ||
| resultBuilder.setUpdateTime(0L); | ||
| } |
There was a problem hiding this comment.
The PigeonPipelineResult class defines createTime and updateTime as nullable Longs. Instead of setting them to 0L when the source timestamp is null, it would be more consistent to set them to null. This avoids forcing the Dart side to treat 0 as a special case for a missing timestamp.
| if (pipelineResult.getCreateTime() != null) { | |
| resultBuilder.setCreateTime(pipelineResult.getCreateTime().toDate().getTime()); | |
| } else { | |
| resultBuilder.setCreateTime(0L); | |
| } | |
| if (pipelineResult.getUpdateTime() != null) { | |
| resultBuilder.setUpdateTime(pipelineResult.getUpdateTime().toDate().getTime()); | |
| } else { | |
| resultBuilder.setUpdateTime(0L); | |
| } | |
| if (pipelineResult.getCreateTime() != null) { | |
| resultBuilder.setCreateTime(pipelineResult.getCreateTime().toDate().getTime()); | |
| } else { | |
| resultBuilder.setCreateTime(null); | |
| } | |
| if (pipelineResult.getUpdateTime() != null) { | |
| resultBuilder.setUpdateTime(pipelineResult.getUpdateTime().toDate().getTime()); | |
| } else { | |
| resultBuilder.setUpdateTime(null); | |
| } | |
| case "or": | ||
| { | ||
| List<Map<String, Object>> exprMaps = (List<Map<String, Object>>) args.get("expressions"); | ||
| if (exprMaps == null || exprMaps.isEmpty()) { | ||
| throw new IllegalArgumentException("'or' requires at least one expression"); | ||
| } | ||
| if (exprMaps.size() == 1) { | ||
| return parseBooleanExpression(exprMaps.get(0)); | ||
| } | ||
| // BooleanExpression.or() takes exactly 2 parameters, so we chain them | ||
| BooleanExpression result = parseBooleanExpression(exprMaps.get(0)); | ||
| for (int i = 1; i < exprMaps.size(); i++) { | ||
| BooleanExpression next = parseBooleanExpression(exprMaps.get(i)); | ||
| result = BooleanExpression.or(result, next); | ||
| } | ||
| return result; | ||
| } |
There was a problem hiding this comment.
The implementation for the "or" expression is inconsistent with the "and" expression. The "and" case correctly delegates to ExpressionHelpers.parseAndExpression, but the "or" case re-implements the logic by chaining BooleanExpression.or() in a loop. To improve consistency and reduce code duplication, this should also use the helper method ExpressionHelpers.parseOrExpression.
case "or":
{
List<Map<String, Object>> exprMaps = (List<Map<String, Object>>) args.get("expressions");
return ExpressionHelpers.parseOrExpression(exprMaps, this);
}| } else if ("or".equals(operator)) { | ||
| if (exprMaps == null || exprMaps.isEmpty()) { | ||
| throw new IllegalArgumentException("'or' requires at least one expression"); | ||
| } | ||
| if (exprMaps.size() == 1) { | ||
| return parseBooleanExpression(exprMaps.get(0)); | ||
| } | ||
| // BooleanExpression.or() takes exactly 2 parameters, so we chain them | ||
| BooleanExpression result = parseBooleanExpression(exprMaps.get(0)); | ||
| for (int i = 1; i < exprMaps.size(); i++) { | ||
| BooleanExpression next = parseBooleanExpression(exprMaps.get(i)); | ||
| result = BooleanExpression.or(result, next); | ||
| } | ||
| return result; | ||
| } |
There was a problem hiding this comment.
This block duplicates the logic for parsing an "or" expression. To improve maintainability and align with the parsing of "and" expressions, please delegate this to the ExpressionHelpers.parseOrExpression helper method.
} else if ("or".equals(operator)) {
return ExpressionHelpers.parseOrExpression(exprMaps, this);
}| @SuppressWarnings("unchecked") | ||
| static BooleanExpression parseAndExpression( | ||
| @NonNull List<Map<String, Object>> exprMaps, @NonNull ExpressionParsers parser) { | ||
| if (exprMaps == null || exprMaps.isEmpty()) { | ||
| throw new IllegalArgumentException("'and' requires at least one expression"); | ||
| } | ||
|
|
||
| BooleanExpression first = parser.parseBooleanExpression(exprMaps.get(0)); | ||
| if (exprMaps.size() == 1) { | ||
| return first; | ||
| } | ||
|
|
||
| BooleanExpression[] rest = new BooleanExpression[exprMaps.size() - 1]; | ||
| for (int i = 1; i < exprMaps.size(); i++) { | ||
| rest[i - 1] = parser.parseBooleanExpression(exprMaps.get(i)); | ||
| } | ||
| return Expression.and(first, rest); | ||
| } | ||
|
|
||
| /** | ||
| * Parses an "or" expression from a list of expression maps. Uses Expression.or() with varargs | ||
| * signature. | ||
| * | ||
| * @param exprMaps List of expression maps to combine with OR | ||
| * @param parser Reference to ExpressionParsers for recursive parsing | ||
| */ | ||
| @SuppressWarnings("unchecked") | ||
| static BooleanExpression parseOrExpression( | ||
| @NonNull List<Map<String, Object>> exprMaps, @NonNull ExpressionParsers parser) { | ||
| if (exprMaps == null || exprMaps.isEmpty()) { | ||
| throw new IllegalArgumentException("'or' requires at least one expression"); | ||
| } | ||
|
|
||
| BooleanExpression first = parser.parseBooleanExpression(exprMaps.get(0)); | ||
| if (exprMaps.size() == 1) { | ||
| return first; | ||
| } | ||
|
|
||
| BooleanExpression[] rest = new BooleanExpression[exprMaps.size() - 1]; | ||
| for (int i = 1; i < exprMaps.size(); i++) { | ||
| rest[i - 1] = parser.parseBooleanExpression(exprMaps.get(i)); | ||
| } | ||
| return Expression.or(first, rest); | ||
| } |
There was a problem hiding this comment.
The logic in parseAndExpression and parseOrExpression is very similar. To improve maintainability and reduce code duplication, consider extracting the common logic into a private helper method. This helper could accept the list of expression maps, the parser, and a functional interface representing the specific logical operation (Expression.and or Expression.or).
Description
Replace this paragraph with a description of what this PR is doing. If you're modifying existing behavior, describe the existing behavior, how this PR is changing it, and what motivated the change.
Related Issues
Replace this paragraph with a list of issues related to this PR from the issue database. Indicate, which of these issues are resolved or fixed by this PR. Note that you'll have to prefix the issue numbers with flutter/flutter#.
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes (
[x]).This will ensure a smooth and quick review process. Updating the
pubspec.yamland changelogs is not required.///).melos run analyze) does not report any problems on my PR.Breaking Change
Does your PR require plugin users to manually update their apps to accommodate your change?