Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Notify queries when executing group statements with result #5006

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 1 commit into from
Mar 20, 2025
Merged

Notify queries when executing group statements with result #5006

merged 1 commit into from
Mar 20, 2025

Conversation

vitorhugods
Copy link
Contributor

@vitorhugods vitorhugods commented Feb 4, 2024 •
edited
Loading

Fixes:

Proposed solution

By modifying the QueryGenerator to make sure all child classes have access to tablesUpdated(), and centralising the query notification into the executeBlock function, make sure the following is added to the generated code of grouped statements.

} .also {
    notifyQueries(queryId) { emit ->
      // emit table names
    }
}

I am not completely sure of this approach and I'd love some feedback before I dedicate more time into it.

To be solved yet

Annoying space before .also {. I'll learn a bit more of Kotlinpoet :)

Questions

  • What's the importance of the Query ID? I noticed in some tests it is hardcoded, in some it figures it out from the compiler. I can modify the notifyQueriesBlock() to accept the QueryId and make it match one of the statements.

Remark

I am not sure about the executeBlock. I find its control flow a bit hard to follow and I'd love to simplify a bit and maybe link the QueryGenerator's implementations more closely to implement it depending on what the query looks like, instead of having too many ifs and elses.

@vitorhugods vitorhugods changed the title fix: W.I.P. make sure notify is called when executing group statements with result fix: notify queries when executing group statements with result Feb 5, 2024
@vitorhugods vitorhugods mentioned this pull request Feb 5, 2024
Closed
@Skaldebane
Copy link

Any updates on this?

@JakeWharton JakeWharton changed the title fix: notify queries when executing group statements with result Notify queries when executing group statements with result Dec 15, 2024
@matt18224
Copy link

Hello!

We have migrated to SQLDelight following the Realm deprecation, but this is a major issue for us.

This bug makes it much more complex to build a reactive app that responds to upserted data. We have many nested relationships in our data and using the SQLite upsert makes it easy to establish these relationships using the returned row ID while hiding whether a new row was added or an existing row updated (since it doesn't actually matter for most of our app).

To get live updates to the DB data without this bug fixed, we will have to explicitly query a row, check if it's null, call an insert query if missing and then grab the last inserted rowid via another query; and if it's not null, grab the existing key and perform an update query instead for every single entity relationship we have. Being able to return the inserted/updated key hides this complexity from the app and keeps DB operations neatly in the SQL.

Any updates on this PR would be really appreciated!

@dellisd
Copy link
Collaborator

dellisd commented Mar 19, 2025

I think this approach makes sense to me.

Annoying space before .also {. I'll learn a bit more of Kotlinpoet :)

This isn't something we need to be concerned about. Kotlinpoet will output what it outputs, it doesn't need to be pretty-printed.

What's the importance of the Query ID? I noticed in some tests it is hardcoded, in some it figures it out from the compiler. I can modify the notifyQueriesBlock() to accept the QueryId and make it match one of the statements.

The Query ID is a hash based on the name of the query and is stable between runs. Getting it from the compiler is "ideal" in the sense that if we were to ever change the way these values were hashed, we wouldn't need to go through and update dozens of tests.

In this case, you can just get it from query.id.withUnderscores, but hardcoding it is also fine.

The query ID refers to the whole grouped query and is used to help dedupe notifications in transactions where the grouped query could be invoked multiple times, so there's no extra work needed to isolate it to one or either of the statements.

@dellisd
Copy link
Collaborator

dellisd commented Mar 19, 2025

If we can get this rebased and the tests fixed up, I think this is ready to merge 👍

@JakeWharton
Copy link
Collaborator

The space is because control flow is the wrong mechanism to use. But it's good enough for now, and produces close enough output.

@vitorhugods
Copy link
Contributor Author

Rebased. Also replaced with hardcoded IDs with query.id.withUnderscores. I'm not sure how I missed it the last time 🙃

@dellisd dellisd merged commit 27b27ca into sqldelight:master Mar 20, 2025
12 checks passed
This was referenced Mar 20, 2025
Closed
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@dellisd dellisd dellisd approved these changes

Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
5 participants
@vitorhugods @Skaldebane @matt18224 @dellisd @JakeWharton