ADF BC: Polymorphism and relations

Question

Hi,
I'm building an ADF 11g application. In our data model, we have a table that contains four different types of transactions, all with the same attributes (columns). One column contains the transaction type and is the discriminator column. We also have customers, and each customer can have different types of transactions. In the database there is a foreign key relation between customers and transactions.
In the user interface, there is a separate screen for each type of transaction. We added each type of transaction as a separate View Usage in the application module and used View Criteria to show only transactions of one kind. But now we want to have some default values set on the transactions and the default values depend on the type of transaction. Since default values are set on Entity Objects, I thought I'd need Entity polymorphism to accomplish this. There is a section on this topic in the [Fusion Developers Guide|http://download.oracle.com/docs/cd/E12839_01/web.1111/b31974/bcadveo.htm#sm0327]. I figure I also need polymorphic view rows, [as described in another section of the dev guide|http://download.oracle.com/docs/cd/E12839_01/web.1111/b31974/bcadvvo.htm#sm0515].
But what I can't find anywhere on the internet is how to use polymorphism with Entity Associations and View Links. I don't want to define links for every sub type. I'd think that it should be enough to define the assocation/link on the top level. But I can't find any documentation on this. Another thing is that it seems that there is no way to have an "abstract" Entity or View Object. We have four types of transactions, let's call them A, B, C and D. On the Entity side, I'd like to have an abstract TransactionEO and four concrete Transaction+X+EO's. (Where X is one of the four types.) But it seems ADF BC forces me to use one of the four types as the default type and use that default type as the super class. Am I missing something here?
To summarize, I'd like the following questions to be answered:
<ol><li>How to use polymorphism in conjunction with Entity Associations and/or View Links?</li>
<li>Is it right that I have to use one of my discriminator values as a default and use that default on the super type? (IOW: Is it right that there cannot be an abstract super Entity?)
</li>
<li>I noticed that a search on "polymorphism" on this forum returned zero results. Does that say anything about how much polymorphism is used in real life projects?</li>
</ol>
Thanks in advance for any help!
Best regards,
Bart Kummel

Answer 1

I'm building an ADF 11g application. In our data model, we have a table that contains four different types of transactions, all with the same attributes (columns). One column contains the transaction type and is the discriminator column. We also have customers, and each customer can have different types of transactions. In the database there is a foreign key relation between customers and transactions.If you want all types of customers to be related to all types of transactions, then:
* Create a BaseCustomer EO, defining its CustomerType attribute as descriminator and leaving the default value NULL for that discriminator attribute. It is not important that any row in the CUSTOMER table actually have a NULL value for the discrminator.
* Create a BaseTransaction EO, defining its TransactionType attribute as descriminator and leaving the default value NULL for that discriminator attribute
* Associate them
Then any subtypes of BaseCustomer and any subtypes of Customer inherit this association, and any common code/attributes that are relevant to all customers and all transactions can live in this base class. It's not formally marked as "abstract" in the metadata, but for all intents and purposes it is your abstract EO if there never exists any row in the CUSTOMER table with CustomerType of NULL or any row in the TRANSACTION table with TxnType of NULL.
In the user interface, there is a separate screen for each type of transaction. We added each type of transaction as a separate View Usage in the application module and used View Criteria to show only transactions of one kind. But now we want to have some default values set on the transactions and the default values depend on the type of transaction. Since default values are set on Entity Objects, I thought I'd need Entity polymorphism to accomplish this. There is a section on this topic in the [Fusion Developers Guide|http://download.oracle.com/docs/cd/E12839_01/web.1111/b31974/bcadveo.htm#sm0327].
You'll need a view object with polymorphic entity usages, and will need to use the CreateWithParameters built-in operation to supply the discriminator attribute value at row create time so the framework knows what EO subtype you'd like the new view row to have.
I figure I also need polymorphic view rows, [as described in another section of the dev guide|http://download.oracle.com/docs/cd/E12839_01/web.1111/b31974/bcadvvo.htm#sm0515].
You would typically need this if either of the following is true:
* Different view row subtypes will be exposing different sets of attributes
* Different view row subtypes will require different sets of exposed client custom methods (or subtype-specific implementations of common view row custom methods inherited from the base)
In that case, you'd viewlink the base VO's together, and the subtype VO's inherit those view links.
But what I can't find anywhere on the internet is how to use polymorphism with Entity Associations and View Links. I don't want to define links for every sub type. I'd think that it should be enough to define the assocation/link on the top level. But I can't find any documentation on this. Another thing is that it seems that there is no way to have an "abstract" Entity or View Object.I mentioned above the closest thing we have to an "abstract" EO or VO. A base component whose discriminator attribute default value never actually occurs in row data (I used NULL above, but it could be any non-occurring value)
We have four types of transactions, let's call them A, B, C and D. On the Entity side, I'd like to have an abstract TransactionEO and four concrete Transaction+X+EO's. (Where X is one of the four types.) But it seems ADF BC forces me to use one of the four types as the default type and use that default type as the super class. Am I missing something here?See my suggestion above.
Let us know if any other questions pop up trying to implement the suggestions above.