Tag Info

New answers tagged

0

The whole rows or an error status Consider returning the whole rows, at least as a run-time option. In DB inserts you may need to inspect the data that was inserted - since it often will be different from what you sent to the DB; common examples include autogenerated row IDs (that the app will likely immediately need), default values determined by DB, and ...


16

Another option is to return a result object instead of basic types. For example: OperationResult deleteResult = myOrm.deleteById(id); if (deleteResult.isSuccess()) { // .... } With this, if for some reason you need to return the numbers of rows affected, you simply can add a method in OperationResult: if (deleteResult.isSuccess()) { ...


11

I would not recommend any of them. Instead, return nothing (void) on success and throw an exception on failure.


1

"Is this better than that?" is not a useful question when the two alternatives don't do the same thing. If you need to know the affected row count, then you must use version A. If you don't have to, then you can use version B - but any advantage you might gain in terms of less code-writing effort is already gone since you took the trouble to post both ...


11

Returning the number of affected rows is better because it gives additional information about how the operation proceeded. No programmer will blame you because he/she has to write this to check if they got some changes during the operation: if(affectedRows > 0) { // success } else { // fail } but they will blame you when they'll have to know ...



Top 50 recent answers are included