Why does the method databaseManager.commitTransaction call internnaly the saveData()?
In my opinion this is wrong and misleading. The commitTransaction should just do that - commit the started database transaction without trying to post any changes to the database. The application code is expected to call saveData(<record_to_save>) to post the specific changes it needs to be included in a transaction before calling the commitTransaction. Consider this scenario:
The application code modifies 4 records in 4 different tables. Starts a transaction, saves the first 2 records and commits the transaction, after that starts a second transaction, saves the remaining 2 records and commits the second transaction as well.
Currently, Servoy is automatically calling saveData() without any arguments and thus posting all changes upon calling the commitTransaction - what if some of those changes are not “completed” yet? In other words, some of the changed records need some results from the commitTransaction to complete the changes. Right now they are posted along with the rest of the records even though the application code has not called an explicit saveData() for them. At least, there should be an option in the commitTransaction method which allows us to prevent/turn off that automatic call to saveData(). Is there such an option currently?
To complete the analogy, the call to databaseManager.rollbackTransaction does not cancel any changes (and it should not). Please, make the databaseManager.commitTransaction consistent with this and either remove the call to saveData() or at least provide an input argument to this method which allows us to conditionally turn it off.
Rossen,
databaseManager.rollbackTransaction() does call databaseManager.rollbackEditedRecords() internally, so at the moment commit is consistent with rollback.
I do agree that you may want more control in some scenario’s and that it should be possible to commit/rollback with keeping the editing records as before.
In rollback, we would have to revert changes to records that have been saved in the transaction and have been changed again before the rollback, other records could be left.
Since this would mean a change in behaviour we cannot change the current behaviour, it would break existing solutions, however a boolean argument to the commit/rollback methods may be an option.
Please file a change request in our support system, so we can investigate.
Rob
Thanks Rob,
I created a feature request case for this.
My suggestion for a possible implementation of this request is to add an optional boolean argument to the databaseManager.startTransaction:
databaseManager.startTransaction(autoSaveCancelChanges)
This new flag by default will be true (in other words, if not specified, the functionality will be the same as the current implementation). If however a false is passed in, the subsequent call to databaseManager.commitTransaction() will not call saveData() [or if databaseManager.rollbackTransaction() is called, the rollbackEditedRecords() will not be used]
With this approach, only a single method signature will have to be changed and it will ensure that both the commit and the rollback operations use consistent processing. Of course, the commitTransaction & rollbackTransaction could be changes instead and have the optional arguments there but in that case it will be up to the application code to ensure that they are used with the same optional argument.
Thanks again for looking into this.
rgansevles:
databaseManager.rollbackTransaction() does call databaseManager.rollbackEditedRecords() internally, so at the moment commit is consistent with rollback.
Rob, has this always been the case or is that a recent functionality? I agree it should work like this.
rossent:
databaseManager.startTransaction(autoSaveCancelChanges)
This new flag by default will be true (in other words, if not specified, the functionality will be the same as the current implementation). If however a false is passed in, the subsequent call to databaseManager.commitTransaction() will not call saveData() [or if databaseManager.rollbackTransaction() is called, the rollbackEditedRecords() will not be used]
Rossent,
If this request is implemented, then I think it is better to have a general setting and not a setting that you have to set true on each startTransaction.
So databaseManager.setAutoSaveCancelChanges = true/false would be better (similar to setAutoSave true/false)
Martin
Martin,
You have a valid point that a global flag will be better. It even makes sense to tie this to the current setAutoSave flag - this however could cause some breaking changes so probably a new flag will be the way to go.
i personally dont like those global flags either
I prefer to be explicit then the code is clear and it doesnt depend on something you set or did way way back.
So having an boolean inside commitTransaction(saveChangedRecords) and rollbackTransaction(rollbackEditedRecords) that both are default true is way more readable in code and doesnt depend on state that is set somewhere else
If some new developer then sees that code it understands it immediately and you are in full control at the moment you want to commit or rollback.
Hi,
databasemanager methods commitTransaction() and rollbackTransaction() now both have an optional boolean parameter to prevent saving/reverting of edited records.
The default behaviour (boolean argument true) is the same as the current behaviour.
This will be introduced in release 6
Rob
Great !!!
Servoy is realy becoming a mature product.
In the best sence of the word.
I’ve never regretted our choice for Servoy and these kind of features make me more and more convinced.
Regards,