Handling not yet committed objects

0
So for a bit of context, I've got an expense claims application with an association of One Claim has many Expenses. When editing the Claim there is a table within that claim that shows all the expenses associated with it. You can create new expenses and edit or delete them. Now if I commit the expenses the claim itself gets committed which results in incomplete claims in the database. I had a work around where expenses do not commit but merely refresh in client and the claim submit button iterates through all the expenses and commits them, which worked nicely up until I tested editing the individual expenses. Because an expense hasn't been committed until the entire claim is saved, if an expense is opened for edit and then cancelled (with rollback) it will always revert to the last commit (deleting if it's a new expense, or back to what it was when the claim was last saved), if I don't roll back it will look fine on the claim once the expense pop up closes but remain in memory and commit with the change So finally the question: is it possible for me to store the changes temporarily, not in the database, so I can rollback to them when closing a page?
asked
3 answers
0

Have you tried using non persistent objects? You could copy the whole to non persistent entities and when the claim is saved use a microflow to move the non persistent object to their persistant ones. If the non persistent objects can not be used you could also use persistent temp objects.

Regards,

Ronald

answered
1

This is an incredibly common scenario, and there is no neat way to handle this: each solution has drawbacks. You could:

  • Commit the expenses, and set delete behavior on the claim. Now you autocommitted claims are in the database (but you could hide them with a HasBeenSavedManually boolean, which you apply to your grids).
  • Create a tempory domain model, but that greatly reduces you speed of development and maintainability.
  • Create a completely new interaction pattern

Usually, I go for option one, and this is acceptable for the customer. For my latest project, I implemented the last option: I have a master-detail workflow, where a new claim is immediately committed. You can then add information as you go, only preventing saving when the information is clearly incorrect (e.g. a negative claim amount). Then I have a status which indicates if a claim is complete and only if it is complete, it can be submitted. Fianlly, I have task entity which refers to incomplete claims and which has validation messages which need to be fixed by the user before a claim is considered complete.

answered
0

Hi guys,

I actually figured this out on my own eventually by using a Non persist-able object to store any editable values and made my own roll back. Which turns out to be very similar to what Ronald suggested. I'm still testing it but it seems to be working perfectly.

Basically every time you click edit it creates a new instance of the non persist-able, stores all the values, if you click cancel, it simply puts them back.

Rom van Arendonk

The first suggestion was my original solution, but when a claim disappeared in UAT, I fear that this solution opens up the possibility for a claim to autodelete itself if something unexpected happens and somehow that 'savedbyuser' doesn't get changed. for all I know the user might have deleted it himself, but my reaction to that was to find a new way of saving expenses and to improve my audit trails.

Thanks a lot for the answers.

answered