ADF 11g: Lessons Learned in View Object refactoring

Though this is not a common usecase and a lot of you might think why someone will ever do that? But, while implementing solutions which are not tried earlier by developer there might be switches from creating a entity based view object to transient view object or other way round that is, starting with a transient view object and then later decide to make it entity based. Lets take the later case:

Converting a Transient View Object to Entity base View Object: Overall not a very commonly done activity but for those who may need to do it in future to save some efforts. It is just to go to 'Entity Objects' section on your view definition and then to shuttle the required entity object on which you want to base your view object. After this you may add required attributes from your entity using the option 'Add from entity' and can delete the transient attributes no longer needed.

So, what't the issue?

Well, if you go ahead with that view object definition and create a table based on a view instance of this view object you will see if coming nice. Try CRUD operations like create, update etc. and should be working as expected.  However, when I tried deleting a row it didn't work at all! So, I decided to debug it and one of the obvious way is set a debug point at remove() method of View object's row impl class and entity object's impl class. On debugging, what I found was: it was hitting the remove method in View Object's row Impl but was not stopping at entity object's impl. This indicated me some sort of configuration issues and I decided to create another view object based on the same entity object but this time in the natural expected way. On doing so in less than 2 minutes and spending some 5 minutes in comparing both the VO definitions carefully I found that in my original view object a property is set in the EntityUsages as follows:


    Name="CreditReceiverEO"
    Entity="myapps.model.entity.CreditReceiverEO"
    DeleteParticipant="false"/>

And this explained everything. So, this property was probably set during the transient view creation and didnt get removed when I switched the VO to base on an entity object.

Conclusions:  

1. Avoid shortcuts in creating ADF BC objects unless you really understand the in and out of xml files generated.

2. Whenever you see and awkward behavior try to do the things in natural way by keeping a backup of your existing app so that you can revert back later if needed.

3. If point 2 is not a valid option all the time then just to create a copy or sample project with the same setup but in the natural manner and compare the generated xmls to see if you can find a clue.

Changes to VO query edit in ADF 11g Jdeveloper 11.1.2

New jdev 11.1.1.2  VO query edit now shows test and explain instead of test. This is very nice and much more productive than earlier versions.

A note about in memory filtering on View Objects in ADF 11g

Very recently a friend encountered following issue in his adf 11g based fusion web application development. He wanted to fetch the rows from the db table just once and there after wanted to do in memory searching. His view object was a sql based view object.

Issue: He could see after first vo.executeQuery()  showing some row count. But after applying a view criteria programmatically and setting vo query mode to QUERY_MODE_SCAN_VIEW_ROWS the row count after vo.executeQuery() was coming 0. 

Solution: Well he missed to set the VO tuning to fetch all rows at once. Without this, VO query was fetching only few rows from db when query was executing for the first time. And there were no rows in the VO cache matching to his filter criteria.