Skip to content
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.

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

docs: limitation when selecting related object that was modified by n after insert trigger #3254

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

laurenceisla
Copy link
Member

A user noted that the after insert query didn't reflect when selecting the modified related table. So I think it would be nice to add this limitation here and inform that a better alternative would be available in the future.

The details are explained in the note I added to the docs. If the explanation is too verbose, then I'll summarize it further.

Info that backs this up:

Comment on lines 833 to 834
In the future we'll implement the insertions of tables and embedded resources at the same time.
For now, an alternative is to use :ref:`table_functions` instead.
Copy link
Member

Choose a reason for hiding this comment

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

I did not look deeper at the other stuff, but I would not put such a sentence in the docs.

Rather:

Suggested change
In the future we'll implement the insertions of tables and embedded resources at the same time.
For now, an alternative is to use :ref:`table_functions` instead.
An alternative is to use :ref:`table_functions` instead.

After all, you never know what the future holds ;)

Copy link
Member Author

Choose a reason for hiding this comment

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

Wanted to give an idea of "working on it", but yeah, I see that it may be too optimistic.

Copy link
Member

Choose a reason for hiding this comment

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

One more thought of this: Would you consider this a bug? The wording you took sounds like it. As such, I would not even add a note at all, but just create an issue in the bugtracker? The issue could then mention the workaround. We should not document bugs, I guess..

Copy link
Member Author

@laurenceisla laurenceisla Feb 26, 2024

Choose a reason for hiding this comment

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

I didn't consider this as a bug at first because of our design choice in executing the entire mutation/selection in a single query (I was wrong there, I said "single transaction" instead of "single query"). It's a PostgreSQL expected behavior so the mention of a heads-up seemed OK to me, in case someone encountered this.

But I get how this could be considered a bug if the design is prone to change. I'll open an issue regardless, with a full example to see if it's worth documenting or just track as bug.

Copy link
Member Author

Choose a reason for hiding this comment

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

Added the issue #3286

Also, NVM the workaround, a more complicated query (with json aggregates) needs to be done in the function.

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

Successfully merging this pull request may close these issues.

2 participants