ADF BC: Creating updatable VO based upon DB View with "instead of" trigger

Question

Hello all,
I have got an interesting issue. I have an Oracle DB view that is used to hide some complexity in the underlying DB design (it does some unions). This view is updatable because we have created an "instead of" update trigger to update the correct table when a row is updated. This is working fine in SQL.
Next, we have created an ADF Entity object based upon the view, specifying an appropriate PK for the DB View. Then, we have created an updatable VO based upon the EO. All well and good so far. The issue we have is in trying to commit changes to the DB - because the ADF BC framework is trying to lock the row to update (using SELECT ... FOR UPDATE), it's not working because of ORA-02014 - cannot select FOR UPDATE from view with DISTINCT, GROUP BY, etc.
This leads me to thinking about overridding doSelect() on the EO as hinted here http://radio.weblogs.com/0118231/stories/2005/07/28/differenceBetweenViewObjectSelectAndEntityDoselectMethod.html
As a temporary test, we have over-ridden the EO's doSelect to call super.doSelect(false) and it does work, although we will have lost update issues as detailed in Steve's article.
My questions:
1). Is overriding doSelect() the correct thing here? Perhaps there is a better way of handling this problem? I do have a base EO class from which all of the EO's extend, so adding this behavior should be straightforward.
2). Does anyone have example doSelect implementation? I am thinking of overriding doSelect for my EO and calling super.doSelect (lock=false), but then I need to deal with some possible exceptions, no?
Kind regards,
John

Answer 1

Hi John,
I have exactly the same issue as you experienced back in January. I have a complex data modelling requirement which requires the need to pivot rows into columns using ROW_NUMBER() and PARTITION clauses. To hide the complexity from the middle tier, I have created a database view and appropriate INSTEAD OF triggers and mapped my EO to the view. I have overriden the lock() method on the EO implementation class (to avoid ORA-02014) and would like to try the same solution you used with the pl/sql call to lock the record.
My question is, how did you manage the release of the lock if the transaction was not rolled back or committed by your application i.e. if the user closed the browser for instance.
In my naivity, I would like to think that the BC4J framework would release any locks for the database session when it found the servlet session to be terminated however my concern is that the lock would persist and cause complications.
Any assistance greatly appreciated (if you would be willing to supply your lock() method and pl/sql procedure logic I would be even more grateful!).
Many thanks,
Dave
London