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 significantly enhances the Firestore pipeline API by integrating Data Manipulation Language (DML) capabilities. It allows users to perform delete, upsert, and insert operations directly within a pipeline, providing a more powerful and streamlined way to modify data based on pipeline results. This change expands the utility of the pipeline for complex data workflows. 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. Changelog
Activity
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 introduces DML operations (delete, upsert, insert) as new stages in the Firestore pipeline prototype, which is a great extension of its capabilities. The implementation looks solid, adding the necessary stage classes, options, and methods to the Pipeline class.
I've left a few comments with suggestions for improvement:
- In
pipeline.ts, the type check forCollectionReferenceinupsert()andinsert()methods is a bit brittle and can be made more robust and readable by using theisCollectionReferencetype guard. - In
stage.ts, there's some code duplication in theUpsertandInsertstage classes (both in the constructor and_toProtomethod). This could be refactored into a common base class or a helper function to improve maintainability.
| typeof collectionOrOptions === 'string' || | ||
| (typeof collectionOrOptions === 'object' && | ||
| 'type' in collectionOrOptions && | ||
| collectionOrOptions.type === 'collection') |
There was a problem hiding this comment.
The type check for CollectionReference is a bit brittle and is duplicated in the insert method below. It can be simplified and made more robust by using the isCollectionReference type guard, which is exported from ./reference.
For example, if collectionOrOptions is null, typeof collectionOrOptions is 'object', which would cause a TypeError on the 'type' in collectionOrOptions check.
You'll need to import isCollectionReference from ./reference to use it.
typeof collectionOrOptions === 'string' ||
isCollectionReference(collectionOrOptions)| export class Upsert extends Stage { | ||
| get _name(): string { | ||
| return 'upsert'; | ||
| } | ||
|
|
||
| get _optionsUtil(): OptionsUtil { | ||
| return new OptionsUtil({ | ||
| transactional: { serverName: 'transactional' }, | ||
| returns: { serverName: 'returns' }, | ||
| conflictResolution: { serverName: 'conflict_resolution' } | ||
| }); | ||
| } | ||
|
|
||
| constructor(options: StageOptions) { | ||
| super(options); | ||
|
|
||
| if ('collection' in this.knownOptions && typeof this.knownOptions.collection === 'string') { | ||
| const collection = this.knownOptions.collection; | ||
| this.knownOptions.collection = collection.startsWith('/') ? collection : '/' + collection; | ||
| } | ||
| } | ||
|
|
||
| /** | ||
| * @internal | ||
| * @private | ||
| */ | ||
| _toProto(serializer: JsonProtoSerializer): ProtoStage { | ||
| let args: any[] = []; | ||
| if (this.knownOptions.collection) { | ||
| args.push({ referenceValue: this.knownOptions.collection }); | ||
| } | ||
| return { | ||
| ...super._toProto(serializer), | ||
| args | ||
| }; | ||
| } | ||
|
|
||
| _readUserData(context: ParseContext): void { | ||
| super._readUserData(context); | ||
| } | ||
| } |
There was a problem hiding this comment.
The Upsert and Insert classes share identical logic for normalizing the collection path in their constructors and for serializing the collection option in their _toProto methods. This duplication can be avoided by extracting the common logic into a shared base class (e.g., CollectionMutationStage) that both Upsert and Insert can extend. This would improve maintainability and reduce code redundancy.
1 participant
No description provided.