Example to Help Understand the Criteria Mode of a View Criteria

Someone asked me to clarify the meaning of the three Criteria Mode values that you can assign to a view criteria (Database, In-Memory, or Both). Here is an example that I hope helps understand these settings better.

Let's assume you have:

  • An EmpVO view object, based on entity EmpEO, that defines a ViewCriteria "OnlyClerks" containing a single ViewCriteriaItem (Job="CLERK")
  • A second OtherEmpVO, also based on entity EmpEO
  • An EmpModule AM whose data model has instance EmpVO1 of type EmpVO and instance OtherEmpVO1 of type OtherEmpVO
    • The EmpVO1 instance has the OnlyClerks VC applied
Now, let's say the use case is:

  1. Execute query on EmpVO1
  2. Create and insert a new row in OtherEmpVO1, setting Empno=9999, Ename="Joe", and Job="CLERK"
  3. Create and insert another new row in OtherEmpVO1, setting Empno=9998, Ename="Bill", and Job="MANAGER"
Now...

If OnlyClerks VC is of type "Database", then:
  • At step 1, the query from the database will return only clerks.
  • At step 2, the new row created in OtherEmpVO1 with Job="CLERK" will be added also to EmpVO's rowset due to the "association consistency" feature (which you can read more about in section 38.1.2 Maintaining New Row Consistency in View Objects Based on the Same Entity of the dev guide).
  • At step 3, the second new row created in OtherEmpVO1 with Job="MANAGER" with also be added to EmpVO's rowset because the applied view criteria was not enabled to support in-memory filtering.
So, the result is that the user would see new MANAGER row appear in the list of what they might have expected to only contain CLERK rows.

If OnlyClerks VC is of type "In-Memory", then:
  • At step 1, the query from the database will return all rows from the EMP table, however in the process of creating ADFBC view rows for each fetched JDBC row, all of the rows that have Job="CLERK" will qualify by the in-memory VC filter and will be kept, while all of the other rows having Job != 'CLERK' will be ignored. In other words, you fetched more rows from the DB than ended up making it into the middle-tier rowset, wasting DB, network, and appserver CPU resources in the process.
  • At step 2, the new row created in OtherEmpVO1 with Job="CLERK" will be added also to EmpVO's rowset due to the "association consistency" feature because the in-memory filter qualifies the row as belonging to the EmpVO1's rowset.
  • At step 3, the second new row created in OtherEmpVO1 with Job="MANAGER" will not be added to EmpVO's rowset because it does not qualify the in-memory filter.
So, the result is that the user would sees only new CLERK rows in the rowset with CLERKs, however it potentially did a lot of work to query then "reject" all of the rows that had some Job value that was not "CLERK" due to not applying the VC to the database query (but only in-memory).

If OnlyClerks VC is of type "Both", then:
  • At step 1, the query from the database will return only clerks.
  • At step 2, the new row created in OtherEmpVO1 with Job="CLERK" will be added also to EmpVO's rowset due to the "association consistency" feature because the in-memory filter qualifies the row as belonging to the EmpVO1's rowset.
  • At step 3, the second new row created in OtherEmpVO1 with Job="MANAGER" will not be added to EmpVO's rowset because it does not qualify the in-memory filter.
So, the result is that the user would sees only new CLERK rows in the rowset with CLERKs and they did only the necessary database work to retrieve the CLERK rows over the network and didn't have to reject any due to in-memory comparison failing.
Comments:

Post a Comment:
Comments are closed for this entry.
About
Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today