Hi, 1.2.x stream contains certain changes that attempt to cache the target SQL for reuse. In the process of capturing this target SQL, this change modified certain critical pathways where OpenJPA builds the Select query -- which depends upon the fetch plan and can get quite complicated as in your case. Several previous reported issues have been tracked to these changes.
Caching of target SQL for reuse has since been redesigned in 2.0.x stream and currently only available in the trunk. Trial performance experimentation had so far shown positive results especially if the queries are complex (involves multiple joins, for example) and frequently executed across different EntityManagers. We are interested to know from the developers/users about relative performance characteristics of this new SQL cache and also any regression it may have caused. The cache is currently active by default so that whoever is using trunk version and executing same JPQL query or NamedQuery more than once is helping to test it :) To estimate performance differential, the cache can be switched off with <property name="openjpa.jdbc.QuerySQLCache" value="false"/> Regards -- Pinaki I did observe this error in 1.2.0. Pinaki Poddar wrote: > > Hi, > >> Would it be possible to get this fix in a 1.2.x release? > Did you observer the error in 1.2x? I wrongly thought that it is recent > regression. I will then consider this issue resolved on trunk i.e. 2.0.x > stream. > > > -- View this message in context: http://n2.nabble.com/Issue-with-FetchAttribute-recursionDepth-tp2260751p2354322.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
