But I just noticed a bug and it seems significant-
If there are no matches for the "Select Records" logic in the block, instead of not writing any data to the database, it writes the update to EVERY cell in the column. This seems like a HUGE bug. I can put the update inside of typebot logic but that will just make it all more complex since it is NOT working in the NocoDB block.
@Baptiste This one is kind of critical for me. Why would it ever be better to write a whole column if the filter fails to find a match? And nocoDB cloud doesn't have versioning or rollback at all so this is just danger-zone for me.
Any way you can take a quick look and just make sure values are only written if the filter/search evaluates to a specific row or sets of rows and only writes the value in those rows?
Right now when the search fails it writes the WHOLE collumn.
Ok, I made you a video. Feel free to skip around. But:
Create a nocoDB with a column for the filter and a column for the correlated values. Send an update to nocoDB with typebot, where the filter evaluates the column ID and checks if it is equal to a BLANK value (such as either an empty variable or an empty input for the checed value).
The filter should only select a column where the value is also BLANK if it evaluates to a true column at all. What is happening is it is returing ALL of the rows as meeting the filter. So it is replacing ALL correlated values (to the column you are trying to set) in the WHOLE table.
If the filter evaluates to an empty variable or a variable with no value, NOTHING in the table should change at all.
In the video- I also thought there was in issue with entering the ID variable as a number but in the video it did it correctly so don't worry about that part.. About 5:15 to 6:55 you can ignore it actually works correctly.
But the filter evaluating to blank does definitely rewrite the entire column.
Just skip to the last minute or so to see the issue quickly.
It's just if the filter is checking a column value against either a blank variable or a blank field, it just evaluates as true for every single row for the update.
Found another SMALL issue with the nocoDB implementation.
IF you are searching a table and your filter is set to a variable with no value, it will return the whatever the filter asks for the whole table- so for first: first value, last: last value, all: json array of ALL values in column.
I guess this is fine but I would think if there is no actual matches, it shouldn't return anything (although I can see the utility of not having to set a variable to pull a random value or all values as an array/list). But I would think first or last should require a match.
This is a much smaller issue than the overwriting that happens with the update module as explained above.
