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
Open
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
17 changes: 17 additions & 0 deletions docs/references/api/resource_embedding.rst
Original file line number Diff line number Diff line change
Expand Up @@ -816,6 +816,23 @@ Response:
}
}

.. note::

Selecting a related object right after doing an insert may give unexpected results if said object was modified in a trigger.
For example, let's say there's an ``AFTER INSERT`` trigger on ``films`` that inserts a new record to ``technical_specs``.
Doing the same ``POST`` request as above, but selecting ``select=title,technical_spec(*)`` instead, it would return:

.. code-block:: json

{
"title": "127 hours",
"techinal_specs": null
}

Since PostgREST does the insertion in a single transaction, the selection is done before the changes are made to the related table, that's why the ``technical_specs`` is empty.
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

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.


.. _nested_embedding:

Nested Embedding
Expand Down