Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>You are trapped in <a href="http://www.wissel.net/blog/d6plinks/SHWL-7PNDF7" rel="nofollow">performance hell</a>. Read access protection is only and only stored inside the document. So when you ask your view navigator to get the count its only option is to open all involved documents - hence the poor performance. Read protection and performance are natural enemies (just imagine: you have an office where every door is locked and to move around you have to check all your keys every time if you have one with the matching lock number).</p> <p>The way out of reader field introduced performance hell is to read only the entries you actually need (<a href="http://www.wissel.net/blog/d6plinks/SHWL-7PNDF7" rel="nofollow">as outlined</a>). It could be a little tricky if a user has access to documents based on name, group-membership and role (that would make one read per access), but it is still very much feasible. In this case you would use a repeat control and a object data source or managed bean, so the multiple passes happen in the background.</p> <p>Bonus trick: if you add a column with the formula 1 (just the number) and add it up, while categorizing it, then you can just jump from naventry to next sibling (that would be the next category) and add the numbers --> much less reads involved and NO documents opened.</p> <p>To stress again: nav.count needs to open all documents and is a BAD idea, anything that requires read access to be checked is a bad idea, so using one (or more) viewNav based on access rights that actually only read documents the user can read is the way to go.</p> <p>Let me know if you need more hints</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload