Codestin Search App

ellemouton · 2025-09-03T12:49:40Z

The SQL* helpers are meant to always set the Valid field of the sql.Null* type to true. Otherwise they cannot be used to set a valid, empty field. In this commit, the SQLStr helper is fixed so that we can represent a valid/set empty string field.

This is important for something like storing node announcement data where fields like Alias might be present but might be a zero length string. The difference is important so that when we construct a pure TLV message, we know wether to include the field or not.

We need this for #9795

gemini-code-assist

Summary of Changes

Hello @ellemouton, 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 addresses a subtle but important bug in the SQLStr helper function within the sqldb package. The fix ensures that empty strings are properly converted to sql.NullString instances where the Valid field is set to true, thereby allowing for the correct representation of non-NULL, empty string values in database operations.

Highlights

Bug Fix: The SQLStr helper function has been fixed to correctly handle empty strings. Previously, an empty string input would result in a sql.NullString with Valid set to false, incorrectly treating it as a NULL value. Now, it consistently sets Valid to true, allowing empty strings to be represented as valid, non-NULL values.
Consistency: This change aligns SQLStr with the intended behavior of other SQL* helper functions, which are designed to always set the Valid field to true for their respective sql.Null* types.

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 in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

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 issue 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.

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 fixes the SQLStr helper to correctly handle empty strings by always setting the Valid field to true on the returned sql.NullString. This makes it consistent with other SQL* helpers and allows storing valid, empty strings in the database. The change is correct and improves the codebase. I've added one suggestion to improve the function's comment to be more descriptive about its behavior, in line with the repository's style guide for exported functions.

sqldb/sqlutils.go

ViktorT-11

Leaving some potential useful extra info for regarding this change in the sqldb package :).

ViktorT-11 · 2025-09-03T13:17:38Z

sqldb/sqlutils.go

-	if s == "" {
-		return sql.NullString{}
-	}


Should this change maybe be optional when using the this function, or have another helper function that does adds this change?

As we are moving to sqldb/v2 this change will be present in that package as well, and when we are utalizing this functionality in other repos we will need to update the logic for cases where we use this function otherwise.
Such as here:
https://github.com/lightninglabs/lightning-terminal/blob/bce4c049a95a8484b04eddbf856c9356c8a64833/session/sql_migration.go#L349

We could also utalize this function for a lot of cases in litd if we do not change the current logic, such as here:
https://github.com/lightninglabs/lightning-terminal/blob/bce4c049a95a8484b04eddbf856c9356c8a64833/firewalldb/actions_sql.go#L74-L88

I think we potentially also need to change the logic here in lnd with this change?

lnd/invoices/sql_store.go

Lines 229 to 231 in ea6cc81

PaymentRequest: sqldb.SQLStr(string(

invoice.PaymentRequest),

),

yeah it's tricky cause i think it should never have been like this in the first place.

but yes, good idea. I'll leave the existing one as is so as not to break existing callers & then i'll add a new function with the desired behaviour.

ViktorT-11 · 2025-09-03T13:33:02Z

Also noticed that tapd uses the same definition as the current logic:
https://github.com/lightninglabs/taproot-assets/blob/21fb82b5c7da2d77f39e01dc3cd50f099c5e9609/tapdb/sqlutils.go#L89

So when tapd moves to sqldb/v2 we'd need to update cases that utalizes that function in tapd as well, unless we update tapd to use the same logic as this PR prior to moving to sqldb/v2.

The SQL* helpers are meant to always set the `Valid` field of the sql.Null* type to true. Otherwise they cannot be used to set a valid, empty field. However, we dont want to break the behaviour of the existing SQLStr helper and so this commit adds a new helper with the desired functionality.

ziggie1984 · 2025-09-03T21:16:43Z

Why don't we keep the null string instead of creating a DB entry which is an empty string. Is the reason because some nodes might send us some data where this data is set to an empty string and the signature covers this empty data ?

ellemouton · 2025-09-04T06:31:47Z

@ziggie1984 - yes exactly.

we use the same nodes table for both v1 & v2 data. in v1, the alias will always be present even if it is a zero length string. In v2 it might not be present at all or it might be present with a zero length string. We need to know which it is so we can reconstruct the original node announcement message exactly so that the sig is still valid

ziggie1984

lgtm

ViktorT-11

Thanks a lot for the changes 🎉!

gemini-code-assist bot reviewed Sep 3, 2025

View reviewed changes

sqldb/sqlutils.go Show resolved Hide resolved

ellemouton added the no-changelog label Sep 3, 2025

ellemouton requested review from bhandras and ziggie1984 September 3, 2025 12:57

bhandras approved these changes Sep 3, 2025

View reviewed changes

ellemouton mentioned this pull request Sep 3, 2025

[epic]: graph db: SQL implementation & migration #9795

Closed

84 tasks

ViktorT-11 reviewed Sep 3, 2025

View reviewed changes

ellemouton force-pushed the fixSQLStrHelper branch from cb5c342 to 40b2796 Compare September 3, 2025 13:47

ellemouton requested a review from ViktorT-11 September 4, 2025 06:32

ziggie1984 approved these changes Sep 4, 2025

View reviewed changes

ViktorT-11 approved these changes Sep 4, 2025

View reviewed changes

ellemouton merged commit d9647f8 into lightningnetwork:master Sep 4, 2025
35 of 39 checks passed

ViktorT-11 mentioned this pull request Sep 4, 2025

sqldb/v2 as separate package #10175

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Comments

sqldb: fix SQLStr helper#10193

sqldb: fix SQLStr helper#10193
ellemouton merged 1 commit intolightningnetwork:masterfrom
ellemouton:fixSQLStrHelper

ellemouton commented Sep 3, 2025 •

edited

Loading

Uh oh!

gemini-code-assist bot left a comment

Uh oh!

gemini-code-assist bot left a comment

Uh oh!

Uh oh!

ViktorT-11 left a comment

Uh oh!

ViktorT-11 Sep 3, 2025

Uh oh!

ellemouton Sep 3, 2025

Uh oh!

ViktorT-11 commented Sep 3, 2025

Uh oh!

ziggie1984 commented Sep 3, 2025 •

edited

Loading

Uh oh!

ellemouton commented Sep 4, 2025

Uh oh!

ziggie1984 left a comment

Uh oh!

ViktorT-11 left a comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

	PaymentRequest: sqldb.SQLStr(string(
	invoice.PaymentRequest),
	),

Comments

Conversation

ellemouton commented Sep 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Summary of Changes

Highlights

Footnotes

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

Uh oh!

ViktorT-11 left a comment

Choose a reason for hiding this comment

Uh oh!

ViktorT-11 Sep 3, 2025

Choose a reason for hiding this comment

Uh oh!

ellemouton Sep 3, 2025

Choose a reason for hiding this comment

Uh oh!

ViktorT-11 commented Sep 3, 2025

Uh oh!

ziggie1984 commented Sep 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ellemouton commented Sep 4, 2025

Uh oh!

ziggie1984 left a comment

Choose a reason for hiding this comment

Uh oh!

ViktorT-11 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

ellemouton commented Sep 3, 2025 •

edited

Loading

ziggie1984 commented Sep 3, 2025 •

edited

Loading