In this topic: http://www.servoy.com/forum/viewtopic.php?f=22&t=15522&hilit=afterRecordInsert there is a statement that databaseManager.saveData() does not work when called within the context of an afterRecordInsert/Update/Delete event callback. As explained, the reason for this is to avoid possible recursive calls.
Is it possible to change the default behavior so that databaseManager.saveData can be used inside the afterXXXXX table events and if a recursion occurs, to either throw and exception or accept N levels of recursion (for example, in MS SQL Server, there is a maximum level of recursion for the table triggers which I believe is 30)? The presumption that a specific method call might lead to a recursive calls and infinite loop should not be the determining factor to disable such useful functionality! It is the same as if you prevent us using for… loops just because someone might write it incorrectly and create an infinite loop. At least, provide an option where the current behavior is the “default” one but we can change it so databaseManager.savaData() is functional within the table events and it is up to us(developers) to make sure that it is used correctly (or better yet, if you detect infinite loop at runtime, throw an exception).
We are trying to use these table events for custom data event driven automation and having this functionality disabled is a big issue. I believe that the suggestions above can be applied to improve the system without “breaking” any existing code. I am curious if there are any plans to enable the requested functionality or are there any workarounds for it? In our case, the client sessions work with databaseManager.setAutoSave(false) and all our transactions commit only records which are saved explicitly (i.e. we use databaseManager.commmitTransaction(false)).
in servoy 6 we already have some support for that if you do just this somewhere in a script
// calling saveData()
databaseManager.saveData()
<< here everything is saved also when touched in after events.
and in that call some records are saved and afterRecordsInsert events did happen which created records again (or updates)
then after the saveData() call those records are also saved. We test and call recursively saveData() again until all are saved.
jcompagner:
in servoy 6 we already have some support for that if you do just this somewhere in a script
// calling saveData()
databaseManager.saveData()
<< here everything is saved also when touched in after events.
and in that call some records are saved and afterRecordsInsert events did happen which created records again (or updates)
then after the saveData() call those records are also saved. We test and call recursively saveData() again until all are saved.
In our case, we never call databaseManager.saveData() with no arguments - we save only the explicitly specified records/foundsets and only those are included in the database transactions.
Under that condition, whatever is changed in the table events does not get saved (even worse, the saveData() returns true but actually nothing happens!)
yes then we don’t do it, because if you want to save record X we are not suddenly also going to save record Y or Z
what do you mean with nothing happens? Record X got saved right?
But currently we don’t have support for saveData() called when save data happens…
You could create an jira case for this so that we can look at it for the future.
jcompagner:
yes then we don’t do it, because if you want to save record X we are not suddenly also going to save record Y or Z
what do you mean with nothing happens? Record X got saved right?
But currently we don’t have support for saveData() called when save data happens…
You could create an jira case for this so that we can look at it for the future.
The original record which has triggered the table event does get saved, however the record which is created and “saved” inside the table event is not - and that call to saveData(newRecord) inside the table event returns true and thus “lying”/hiding the actual state of the record.
We definitely are going to create a case for that. All that is needed is a recursive call to the internal implementation of the databaseManager.saveData(<record_to_save>) from within itself. And don’t worry about developers writing infinite loops - this is their problem not yours