The default for the 'key' argument is all columns of the table (e.g. assumption of unique rows).
This is a nice default, but is often less efficient versus actually getting the key (=minimal set of columns) from the user.
With this, deletes and updates require less columns to match on and databases use indices better.
This is especially important because in case of some data types, matching can go wrong.
E.g. sometimes numbers or timestamps do not properly match because of different precision.
editbl however wrongly throws a 'succes' in these cases, because the database doesn't give an error and there's no additional check on whether or not the data actually got deleted or updated.
A combination of the following needs to be implemented:
- Warning or message in case 'key' argument is not used.
- Adjust
e_rows_update / e_rows_delete to support more data types correctly
-> If not resolvable, throw an error in case one of the columns of the key contain a datatype which is known to cause problems.
- Request the amount of deleted rows / updates back from the database and throw error or warning in case of mismatch.
-> Not all backends will support this. Also, this can cause confusion if there were concurrent updates or deletes.
The default for the 'key' argument is all columns of the table (e.g. assumption of unique rows).
This is a nice default, but is often less efficient versus actually getting the key (=minimal set of columns) from the user.
With this, deletes and updates require less columns to match on and databases use indices better.
This is especially important because in case of some data types, matching can go wrong.
E.g. sometimes numbers or timestamps do not properly match because of different precision.
editbl however wrongly throws a 'succes' in these cases, because the database doesn't give an error and there's no additional check on whether or not the data actually got deleted or updated.
A combination of the following needs to be implemented:
e_rows_update/e_rows_deleteto support more data types correctly-> If not resolvable, throw an error in case one of the columns of the key contain a datatype which is known to cause problems.
-> Not all backends will support this. Also, this can cause confusion if there were concurrent updates or deletes.