You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, bindings::query::update_by_field does a delete, ignores its result, then unconditionally calls insert, again ignoring its result. Consider what behavior we want and what is least surprising to users. My (pgoldman 2024-05-20) theory is that it should only call insert if a delete happened, and then should return the return value of insert.
Alter bindings::query::update_by_field to only call Table::insert if it actually deleted a row. It should also return the inserted row, as autoinc columns may still be updated within it.
Also consider making it an error to do update_by_{col} and supply a role which has a non-matching value in the col, like Foo::update_by_foo(&0, Foo { foo: 1, ..Default::default() }).
The text was updated successfully, but these errors were encountered:
Currently,
bindings::query::update_by_field
does a delete, ignores its result, then unconditionally callsinsert
, again ignoring its result. Consider what behavior we want and what is least surprising to users. My (pgoldman 2024-05-20) theory is that it should only call insert if a delete happened, and then should return the return value ofinsert
.Alter
bindings::query::update_by_field
to only callTable::insert
if it actually deleted a row. It should also return the inserted row, as autoinc columns may still be updated within it.Also consider making it an error to do
update_by_{col}
and supply a role which has a non-matching value in thecol
, likeFoo::update_by_foo(&0, Foo { foo: 1, ..Default::default() })
.The text was updated successfully, but these errors were encountered: