Skip to content

Conversation

@sheing-google
Copy link

This commit adds logging of the expression result in GormValue for both stateMap and dynamicJSON types in session/database/gorm_datatypes.go. It uses db.Logger.Info to log the result if a logger is configured. This resolves the TODOs in the code.

This commit adds logging of the expression result in `GormValue` for both `stateMap` and `dynamicJSON` types in `session/database/gorm_datatypes.go`.
It uses `db.Logger.Info` to log the result if a logger is configured.
This resolves the TODOs in the code.
@google-cla
Copy link

google-cla bot commented Dec 4, 2025

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

@gemini-code-assist
Copy link
Contributor

Summary of Changes

Hello @sheing-google, 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 improves the debuggability and observability of GORM operations within the session/database package. It specifically adds logging capabilities to the GormValue methods for stateMap and dynamicJSON types, ensuring that the data being processed by GORM expressions is recorded when a logger is active. This change directly resolves previously noted areas for improvement in the codebase.

Highlights

  • Enhanced Logging: Introduced logging for the expression results within the GormValue methods of both stateMap and dynamicJSON types.
  • Conditional Logging: Logging is performed using db.Logger.Info only if a logger is configured, preventing unnecessary operations.
  • TODO Resolution: Addressed and resolved existing TODO comments in the session/database/gorm_datatypes.go file related to logging expression results.
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.

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request adds logging for GORM expression values as intended, resolving the TODOs in the code. The implementation is straightforward. However, I've pointed out a high-severity issue in stateMap.GormValue where a potential error from json.Marshal is ignored. This could lead to silent failures and incorrect database operations. While the change itself is correct in adding logging, it misses an opportunity to make the code more robust by handling this error.

This commit adds logging of the expression result in `GormValue` for both `stateMap` and `dynamicJSON` types in `session/database/gorm_datatypes.go`.
It uses `db.Logger.Info` to log the result if a logger is configured.
It also logs an error if `json.Marshal` fails during `GormValue`.
This resolves the TODOs in the code.
@sheing-google
Copy link
Author

/gemini review

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request adds logging for GORM expression generation in stateMap and dynamicJSON types, resolving a TODO. The implementation for dynamicJSON is correct. However, the implementation for stateMap could lead to silent data loss if json.Marshal fails. I've provided a review comment with a suggestion to refactor the logic to handle marshalling errors more robustly by returning a NULL expression, which also simplifies the code structure. Overall, a good improvement with that one correction.

Comment on lines +92 to 100
data, err := json.Marshal(sm)
if db.Logger != nil {
if err != nil {
db.Logger.Error(ctx, "GormValue json.Marshal error: %v", err)
} else {
db.Logger.Info(ctx, "GormValue expression result: %s", string(data))
}
}
return gorm.Expr("?", string(data))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

While adding logging is great, the current implementation has a potential issue. If json.Marshal fails, the error is logged, but the function proceeds to return gorm.Expr("?", "") because data will be nil. This results in an empty string being stored in the database, which might mask the marshalling error. It would be more robust to handle the error explicitly and return a NULL expression, which is a clearer representation of failed data generation. This also simplifies the logic by removing nested if statements.

data, err := json.Marshal(sm)
if err != nil {
	if db.Logger != nil {
		db.Logger.Error(ctx, "GormValue json.Marshal error: %v", err)
	}
	return gorm.Expr("NULL")
}

if db.Logger != nil {
	db.Logger.Info(ctx, "GormValue expression result: %s", string(data))
}
return gorm.Expr("?", string(data))

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant