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.

More: continued here

Post By Editor (2,827 Posts)

Website: →

Connect