Introduction
The declarative SQL mode is considered to be one of the most valuable advantages of the entity-based view objects. In this mode the VO's SQL is generated at runtime depending on the attributes showed in UI. For example, if some page contains a table with only two columns EmployeeId and FirstName, then the query will be generated as "select Employee_ID, First_Name from Employees". This feature can significantly improve the performance of ADF application. But what about read-only or SQL-based view objects? JDeveloper doesn't allow you to choose the SQL mode for SQL-based VOs. Оnly "Expert" mode can be used with no chance to have the query generated on the fly. But everything is possible.
In this post we have an example of some SQL-based view object VEmployees:
Let's generate View Object Definition class:
We're going to override some methods:
For the page showing the full set of attributes, we have the result:
And generated query (I use ODL analyzer):
For the page with only two attributes we have the following result:
And the query:
The sample application for this post requires JDeveloper 11.1.2.1.0 and standard HR schema.
The declarative SQL mode is considered to be one of the most valuable advantages of the entity-based view objects. In this mode the VO's SQL is generated at runtime depending on the attributes showed in UI. For example, if some page contains a table with only two columns EmployeeId and FirstName, then the query will be generated as "select Employee_ID, First_Name from Employees". This feature can significantly improve the performance of ADF application. But what about read-only or SQL-based view objects? JDeveloper doesn't allow you to choose the SQL mode for SQL-based VOs. Оnly "Expert" mode can be used with no chance to have the query generated on the fly. But everything is possible.
In this post we have an example of some SQL-based view object VEmployees:
Let's generate View Object Definition class:
We're going to override some methods:
@Override public boolean isRuntimeSQLGeneration() { return true; } @Override public boolean isFullSql() { return false; } @Override //In our case we know exactly the clause FROM public String buildDefaultFrom(AttributeDef[] attrDefs, SQLBuilder builder, BaseViewCriteriaManagerImpl vcManager) { return "Employees"; } @Override //Setting "Selected in Query" property for each attribute except PK protected void createDef() { for (AttributeDef at : getAttributeDefs()) if (!at.isPrimaryKey()) ((AttributeDefImpl) at).setSelected(false); }Actually, that's it! Let's test it.
For the page showing the full set of attributes, we have the result:
And generated query (I use ODL analyzer):
For the page with only two attributes we have the following result:
And the query:
The sample application for this post requires JDeveloper 11.1.2.1.0 and standard HR schema.
Hola! I've been following your blog for some time now and finally got the courage to go ahead and give you a shout out from Austin Texas! Just wanted to say keep up the excellent job!
ReplyDeleteStop by my site search engine
The declarative entity based view will remove joins to tables not selected in the query, but I don't think this will do that will it? And if you use the search panel and search on criteria from tables with attributes not in the page bindings, the extra joins will be added to the query when using declarative entity based views.
ReplyDeleteIn this example the FROM clause is constant. This is "Employees".
DeleteWe have overridden the buildDefaultFrom method because we know exactly the FROM clause in our case. For sure, it's possible to make the method more sophisticated if we really need that.