I am seeing a new issue/bug across all of my apps today that use the Bulk Update via Primary key on a table.
I am triggering this query on a table save. I can see that the changeset properly reflects the changes to a row. Then when the user hits save, I can see for a split second a new record gets added to the changeset. It appears to be what other column/field in the table the user happens to be on when they hit save. The effect is it takes the value in the changset and also writes to the field above if the user has their mouse there, or say in a column called description if they are there.
To make clearer, if they change qty from say 1 to 5, then click out of that field, the changeset array shows the one edit. But wherever else they are with mouse when they hit save, 5 gets updated there as well.
i can see the bug too, i will record a video showing that - it looks really like a fatal bug that affects my app and also overwrites some data in other columns (that shouldnt be toched by save) - my client reported me this today
In the video there are some strange things happening in changesetArray, like automaticaly adding new non-existing column just after i hit save - then i got error like this:
update "Lines" set "line_comment" = $1, "RetoolInternal-e7b3f715-3175-457f-a9f7-010cb089b65c-GroupedColumnId" = $2 where "id" = $3 - column "RetoolInternal-e7b3f715-3175-457f-a9f7-010cb089b65c-GroupedColu" of relation "Lines" does not exist
+1 on this bug
Seems like values in the changesetArray are getting overwritten with random values from the table (or previous update attempts?), resulting in type errors or wrong values saved in wrong columns
it is still not the solution because my users wont select multiple rows before saving. The workaround that @gasperblk provided on Discord is way better and i used it
delete saveaction from table
create new independent button and use it as a save button, you can add some logic to disable if there are no changes in table or the save query is running, it looks like this in my app:
No problem! We just reverted a change that led to some funkiness between the tentative table updates and the selected rows. That's starting to roll out now, will loop back once that's complete.