A user wrote in asking for clarification on polymorphic view objects. He had started by creating a base Emp entity object without a Comm attribute, having its Job attribute marked as the discriminator attribute. Then, he extended Emp to create Clerk entity object as well as a Salesman entity object, in both cases overriding the Job discriminator attribute to set the appropriate default value for that subtype. In the Salesman entity, he added the additional Comm attribute for commission. He wanted to know why his polymorphic view object was not giving him access on the client side to the additional Comm attribute in rows where the Job was equal to 'SALESMAN', the discriminator attribute value for the Saleman entity object. In this entry I try to clarify why the behavior he was seeing is correct, and how to achieve what he wanted to do.
There are two kinds of polymorphic view objects that we support. These two types are documented in Dev Guide sections:
When you use the first kind of polymorphic view object, as this reader was doing, the different entity usage subtypes are opaque to the client. As far as the client layer is concerned, every row in the view object's result set has the same set of attributes and row type, even though under the covers ADFBC ensures that the correct EO row subtype is created based on the discriminator attribute value. In other words, with a polymorphic entity usage, only the entity row parts of a view row are changing type, but the view row type is constant.
The second type of polymorphic view object involves defining a hierarchy of view objects, and then configuring the application module to allow one or more view row subtypes in the result. Only the second type of polymorphism produces different subtypes of client-visible view row types. Only this type allows the client to "see" a subtype of a client view row with an additional attributes.
You can use either type of polymorphism on its own, or combine the two, at your choice. So, to achieve that the reader wanted to accomplish, he would need to define a base EmpView having his base Emp entity object as its entity usage. Then, create ClerkView VO that extends EmpView and SalesmanView that extends Emp. Finally, in the application module editor, he would need to configure ClerkView and SalesmanView as view subtypes to allow for the EmpView view instance. Then, in the client layer, rows for salesmen would have an additional Comm attribute available.
P.S. Another thing that came up in answering his question was that he was allowing the ADF polymorphic discriminator attribute filtering to narrow down the query to only contain the expected subtypes. However, it's not best practice to rely solely on the discriminators to perform type filtering in the query as this will effectively end up querying all rows and then "throwing away" rows that don't qualify any of the disciminator values in the middle tier. See section 27.6.4.1 Your Query Must Limit Rows to Expected Entity Subtypes in the dev guide for more info.
3:12:04 PM 
|
|
