Oh sure, Thanks Jody for hauling me into this discussion...
I will agree that the current usage scenario was not intuitive or documented. And, since we have customers hitting this condition of accidentally caching the "wrong" SQL, I agree that we need to do something in the service streams to resolve the issue. And, considering the 80/20 rule, it seems that erring on the default/conservative side definitely hits the 80% side of the market.
That all being said, Pinaki does have a valid point that we are now alienating users that use fetch plans from using the FinderCache. But, that is also consistent with Pinaki's direction to have the application control whether these generated SQL's should be cached or not. We're just making that decision for them.
Also, does this change in behavior have any impact on the normal callpath from a performance perspective? Pinaki is hinting that it will affect performance. If we are doing additional processing on every generated SQL and access to the FinderCache, then are we negating the benefits of the cache?
One alternative is to modify the FinderCache so that it could take the FetchPlan settings into account. Whether this extra processing would offset the benefit of the cache would have to be determined. Regardless, this is too big of an effort for the service streams. I would suggest creating a sub-JIRA feature for this effort so that we have it on the books. But, stick with this conservative approach until this sub-feature is resolved.
That's my two cents worth. But, don't just re-close this JIRA without coming to some type of agreement. I've posted a few questions that should be discussed and resolved. Thanks.