Use parameter equality for v3 observation requests

[n-h-diaz]

Recommended by spanner team for better query plans

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! 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 refactors the Spanner query building logic to enhance performance for v3 observation requests. By transitioning from generic IN clauses to more specific parameter equality or IN UNNEST with dynamically named parameters, the changes aim to provide Spanner with better information for query plan optimization, ultimately leading to more efficient data retrieval.

Highlights

• Query Optimization for Spanner: Implemented a recommended optimization from the Spanner team to improve query plans by using parameter equality (=) instead of IN clauses for single-value filters in v3 observation requests.
• Refactored Parameter Handling: Generalized the getIdStatement function to getParamStatement to handle dynamic parameter names and values more flexibly, supporting both single and multiple input values for various query types.
• Updated SQL Templates: Modified SQL statement templates to dynamically inject parameter names, allowing for more efficient and flexible query construction based on the number of input values.

Changelog

• internal/server/spanner/golden/query_builder/get_observations.sql
  • Changed the variable_measured filter from an IN clause to an equality (=) operator for single values.
• internal/server/spanner/golden/query_builder/get_observations_entity.sql
  • Changed the observation_about filter from an IN clause to an equality (=) operator for single values.
• internal/server/spanner/query_builder.go
  • Replaced getIdStatement with a new getParamStatement function to handle dynamic parameter names and values.
  • Updated GetNodePropsQuery to use the new getParamStatement for constructing ID filters.
  • Updated GetNodeEdgesByIDQuery to use the new getParamStatement for constructing ID filters.
  • Modified GetObservationsQuery to utilize getParamStatement for dynamically building variable_measured and observation_about filters.
• internal/server/spanner/statements.go
  • Renamed getId and getIds fields to getParam and getParams respectively to reflect their generalized purpose.
  • Updated the SQL templates for getParam and getParams to include fmt.Sprintf placeholders for dynamic parameter name injection.
  • Modified selectVariableDcids and selectEntityDcids templates to accept a formatted string for parameter injection, aligning with the new getParamStatement logic.

Activity

• No human activity has been recorded on this pull request yet.

Using Gemini Code Assist

The 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 /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

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 .gemini/ folder in the base of the repository. Detailed instructions can be found here.

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

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request refactors the query building logic to use SQL equality (=) instead of IN for single-item lists, which is a good optimization for Spanner query plans. The refactoring generalizes the previous getIdStatement into a more flexible getParamStatement, which is a nice improvement for code reuse. The changes are applied to node property/edge queries and observation queries. The logic appears sound. I have a couple of suggestions to improve the readability of variable names in the updated functions.