Hi, Happy new year!
We have the following in the project
1. Created at design time table-based EntityObject EO
2. Crated on basis of EO ViewOject VO
We would like to have
1. If user User1 login to the application then EO will use table TAB1
2. If user User2 login to the application then EO will use table TAB2
where TAB1 and TAB2 have same structure.
The problem is that EO by default is shared accross the all application modules i.e. one EO instance per application, and EO.setSource in one session influence to other sessions.
At this moment we have overriden method getSource of EntityDefImpl and based on session parameter, we return different sources
Has anyone done something like this?
Maybe think about turning this requirement on its head and solving it at the ViewController layer by injecting dynamic bindings. See Duncan Mill's recent blog post:
Hi Chris, thanks for response.
We thought about solution with using dynamic bindings. But in real application TAB1 has several child tables, in turn the tables also have child tables. Besides Tab1 involved in many different forms and task flows. So if use dynamic bindings we need to have two copies all child tables(because of the ViewObject links), and need for all child tables use dynamic bindings too. It's look very cumbersome and I think this solution difficult to control, therefore I do not want to go that way.
Can you take a step back and explain your use case more please? How have you ended up in a situation where you have different tables per user? Is it only 2 different tables, or is it literally a different table per user?
If in two words.
We have table BASE_TABLE.
We have two types users. 1 - users with limited access to the table BASE_TABLE, defined by some rules in database. This type of users usually have access to few rows in table BASE_TABLE. The access is created through database view (TAB1 in my first post). View created in database because most of our business logics implemented in database. 2 - users with unlimited access to the table BASE_TABLE, for such users view TAB1 is very complex and slow, so we decide to make view TAB2, this view is very fast for such users. Both views TAB1 and TAB2 have instead of triggers, so we can modify data through this view. We tried to make complex view TAB1 by using "union all" whith some flags, when works only one part of "union all". But it did not give such a performance boost as a standalone view TAB2.
I can't say I have a solution for you at the ADF side. However what you're attempting to achieve at the database side seems a fit for the Oracle RDBMS Enterprise Edition Virtual Private Database (VPD) feature.
Possibilities of VPD is not enough to implement our complex access rules.
Furthermore, this does not relieve us from the problems of productivity, which we solved by separating the complex view TAB1 into two simple view.