tag:blogger.com,1999:blog-5874979429188093780.post6166841292081555046..comments2024-03-18T06:46:54.352+01:00Comments on Andrej Baranovskij Blog: Why You Don't Want to Code Validation in Before CommitAndrej Baranovskijhttp://www.blogger.com/profile/04468230464412457426noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-5874979429188093780.post-25009741968631687942014-03-16T11:52:20.707+01:002014-03-16T11:52:20.707+01:00The thing is - when you throw exception from befor...The thing is - when you throw exception from beforeCommit, this "backup" view as you say - is removed. As it assumes all changes were committed to DB successfully. I hope this is clear enough from the blog post, try to follow steps visualised in screenshots.<br /><br />Regards,<br />AndrejusAndrej Baranovskijhttps://www.blogger.com/profile/04468230464412457426noreply@blogger.comtag:blogger.com,1999:blog-5874979429188093780.post-7561164015073883482014-03-16T07:13:57.198+01:002014-03-16T07:13:57.198+01:00Thanks for the clarification!
However, as far as ...Thanks for the clarification!<br /><br />However, as far as I know, when ADF loads a view, it keeps a backup copy also to compare with the db state to take the lock before posting/committing the data. And if change indicator is not implemented then all view attributes would be compared to rule out stale data.<br /><br />In this context, I am unable to reconcile steps 1 and 3 you mentioned above. At step 1, view has Steven123 (EO state is not reset) whereas view backup has Steven. Doesn't ADF compare the view with the view backup to find out which fields were modified in the transaction?<br /><br />Thanks again!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5874979429188093780.post-78303639443927972202014-03-10T18:38:33.663+01:002014-03-10T18:38:33.663+01:00Hi,
There is DB pooling enabled, so there will be...Hi,<br /><br />There is DB pooling enabled, so there will be no lock - lock is released at the end of request. Without DB pooling, lock would stay forever and no other user would be able to commit anything in the same record.<br /><br />1. Yes, when commit fails - EO state is not reset back, it assumes all data is successfully posted. From ADF BC point of view, data is successfully stored in DB. Validation was thrown in beforeCommit, this is too late<br /><br />2. ADF doesnt see FirstName as changed anymore during second commit, EO attribute is assumed to be unchanged - so, there is nothing posted to DB for this attribute on the second commit<br /><br />3. No, it doesnt compare FirstName with the value in DB - it simply forgets about recently changed value after first validation error from beforeCommit and assumes FirstName is the same as in in DB - Steven<br /><br />You should move validation rules from beforeCommit into EO validators, as standard recommendation from ADF developer guide. You can call PL/SQL validation rules from EO validators on attribute or EO level.<br /><br />Regards,<br />AndrejusAndrej Baranovskijhttps://www.blogger.com/profile/04468230464412457426noreply@blogger.comtag:blogger.com,1999:blog-5874979429188093780.post-72035308526032640412014-03-08T06:05:06.561+01:002014-03-08T06:05:06.561+01:00I will follow up on this, to clarify your doubts. ...I will follow up on this, to clarify your doubts. Stay tuned.<br /><br />Regards,<br />AndrejusAndrej Baranovskijhttps://www.blogger.com/profile/04468230464412457426noreply@blogger.comtag:blogger.com,1999:blog-5874979429188093780.post-17327282808249959632014-03-07T21:31:24.781+01:002014-03-07T21:31:24.781+01:00Where should we move the beforeCommit business rul...Where should we move the beforeCommit business rules validations? To postChanges for example? postChanges is on commit process too... it'll have the same effects I suppouse. And what happens if we have some business rules on DB on PL/SQL?Yohttps://www.blogger.com/profile/11522710371473979201noreply@blogger.comtag:blogger.com,1999:blog-5874979429188093780.post-77175600925716600732014-03-07T21:07:21.534+01:002014-03-07T21:07:21.534+01:00Shouldn't we expect it to throw a lock error i...Shouldn't we expect it to throw a lock error in this scenario instead of committing only the modified Salary?<br /><br />Here is how I thought it would work, and this must be not the way ADF is actually handling this, so request you to correct it:<br />1. When the first commit fails, the view state is not rolling back to the original values, instead it's keeping the modified values FirstName="Steven123" and Salary="2000"<br />2. Now user modifies the salary to 2500. Upon commit, the first thing ADF would check is which attributes have changed; this it would probably do by comparing with the view's backup template that ADF keeps for resolving locking issues(?)<br />3. It finds "Steven123" and "2000" there for those 2 attributes, so only Salary has changed, and that's what it tries to commit<br />4. But as soon as it compares this view backup copy with the db state, it finds stale data in the view back, and ought to throw a lock error<br /><br />If the view backup actually holds the original values, Steven and 2000 at step 2, then it should have found that both FirstName and Salary have been modified. Or has it something to do with the jsf lifecycle where since the model (bean or bindings) was updated at step 1, when the form is submitted at step 2, it's passing only the updated salary and not the FirstName.<br /><br />Could you please clarify?<br /><br />Thanks!Anonymousnoreply@blogger.com