This refine includes several changes:
1) Reorganize persistence_impl.ftl to break it into pieces for easier reading.
2) Properly handle cache population on success and failure scenarios, to ensure valid state and release BlockingPortalCache.
3) Have a clear definition for single value non-unique finder, to ensure proper cache category usage.
4) Remove ORDER BY clause for unique finders. There is nothing to sort about for unique index.
5) For Collection Finders, change the "order by" rules to this:
a)If orderByComparator is specified, generate a proper order by clause from it
b)If orderByComparator is absent, however pagination is required (a valid start and end), use model entity's default order by(The one you defined in service.xml, if you don't have it, it will default to order by PK).
c)If orderByComparator is absent and pagination is not required. Which means full result set, the generated sql select will have no order by clause to avoid database side sorting(to improve performance), on return to portal, we sort the result set by PK. Sorting on portal side by PK in this case can also help portal side caching, as PK is not changable.
6) Include "order by" columns into FINDER_PATH_WITHOUT_PAGINATION_FIND_BY_*'s bitmask value to proper evict out of date cache. (PK columns are excluded, as they are not changable)
7) For arrayable finder, if the all array parameters happen to have only 1 element, fallback to regular finder to archive better caching performance.
There are two types unique finders, one is declared with unique="true", this is a physical unique ensured on DB side. The other is declared with unique="false" with non-collection return type, this is a logical unique ensured on Portal side.
The logical unique is much weaker than physical unique, it means there could be actually more than 1 row exist for the given query criteria on database side. When that happens, portal will randomly(select without order by) result from all matches rows and log out a warning message for it.
So try to use unique="true" whenever possible, if not, make sure your application logic enforce the unique logic, otherwise you may see this warning and random result.