Showing posts from August, 2011

Compiling large projects from JDeveloper

If you are running in to out of memory error while compiling huge projects from JDeveloper, this tips is for you. JDeveloper will let you to compile the project outside of JDeveloper process where the compiler can enjoy more heap size(which doesn't need to be shared with JDeveloper). To do this select the Project, right click-> Project Properties and select Out of Process option. Optionally you can modify the default heap size as well. Out-of-process compilations are useful for very large projects; an in-process compilation could run out of memory because it shares the memory space with the whole JDeveloper IDE.

What you may need to know about data types for history columns which stores date and time?

When you choose history columns data types to store 'Date', please follow the following points: 1. Always prefer java.sql.Timestamp (or similar) over java.sql.Date for history column attribute type in an entity: Well,apart from the common benefits of using Timestamp over Date, there is one more point. The java.sql.Date will truncate the value(removing time comp) when the data is posted to data base. At this stage the database table is having truncated value and entity object has non truncated date. If the user again modifies the same row on the same date, the row consistence check may fail while posting data to database and you may get the below error oracle.jbo.RowInconsistentException: JBO-25014: Another user has changed the row with primary key... 2. Make sure corresponding history column in database table is of type TIMESTAMP DATE contains the datetime fields YEAR, MONTH, DAY, HOUR, MINUTE, and SECOND. TIMESTAMP stores date and time as small as the nanosecond and

Long living Dynamic Business Components

Recently I came across an interesting post from Juan Oropeza (Oracle) in an internal wiki, the code was illustrating dynamic ViewObject creation which lives beyond user sessions. Thanks to Steve Muench who did help me to understand this thing better. Today's post is on this topic. What is so great about this concept? Well, there are few good stuff for you. Read on... In one of my previous post, I blogged about building dynamic UI - Model driven approach for building Dynamic UI . There the life of a dynamically created view object or entity object were limited to a user session in which they were created. What if you need the dynamically created ADF business components to be available across all user, beyond a specific user session. A real life use case may be adding couple of more attributes or validations on an existing View Object definition at run time which needs be reflected across all users. Well this is quite possible by getting the personalization definition of the V

What you may need to know about useBindVarsForViewCriteriaLiterals in adf-config.xml?

The 11.1.2 release has introduced a new flag useBindVarsForViewCriteriaLiterals in your application's adf-config.xml. <?xml version="1.0" encoding="US-ASCII" ?> <adf-config .... > <adf-adfm-config xmlns=""> <defaults useBindVarsForViewCriteriaLiterals="true" /> ... </adf-adfm-config> ... Idea is to force the run time to generate temporary bind variables instead of directly using literal values while generating WHERE clause for the ViewCriteria. The above said configuration is done at application level which will set ViewCriteria::setUseBindVarsForLiterals(true) for all VC instances. This will help to improve performance of query execution by caching SQLs Reduce/avoid the chance for SQL injection