On 08/13/2012 04:37 AM, Johannes Renner wrote:
On 08/06/2012 05:59 PM, Tomas Lestach wrote:
Hello Johannes,
On Friday 03 of August 2012 12:44:11 Johannes Renner wrote:
Hi,
We found out that commit 16f30f97d657ab7019489dfac5a11f67afc2143e apparently
broke the Errata page for custom channels:
https://<hostname>/rhn/channels/manage/errata/ListRemove.do?cid=XXX
Sorting (by clicking on the columns) as well as filtering the list is broken
and it seems as if the query is not actually elaborated.
You're right here. My fault.
We need to fetch the attributes according to those we want to sort in the
original query - even if they get elaborated later on.
So I am coming up with two patch proposals, since I am not really sure about
how we are intended to solve the problem:
- The first patch fixes it by calling elaborate() manually once
I wouldn't call the elaborate method manually. Since the mechanism has worked
till now, I'd rather revert my original commit.
spacewalk.git: 43fbb66782bebe62e5aa323bc5edf70276d2609b
- The second patch is a more generic fix and calls elaborate() in
BaseManager.java even if PageControl is null
What is the bug you try to fix with the 2nd patch? Could you describe the
misbehavior on a concrete page?
The second patch is just a more generic alternative fix for the same bug:
It makes sure that elaborate() will be called even if PageControl is null. It
fixes
the bug since PageControl is null in the case of the above page. Further I was
just
wondering why would we want to return an unelaborated list in this case?
Since this is probably not how the original mechanism is supposed to work,
could you
maybe please give a short explanation? Who should be calling elaborate() and
when?
Thanks,
Johannes
Hey Johannes,
Sorry for the delay, Thomas had asked me to look at this and it slipped
through the cracks. Elaboration is mainly designed to help improve
performance in when displaying items in a list where part of the list is
not shown (Paginated).
1. You have a fast driving query that queries all object with a given
parameters and joins tables needed to determine if the object is to be
included. It only needs to select the ID attribute as well as
attributes needed for sorting or for the alpha bar (A-Z selector).
2. The manager layer method that runs the query returns the
un-elaborated results.
3. The results are rendered on the page via the list tag, and as part
of that the results are elaborated.
For example, when displaying the systems list, you may have 1000
systems. Calcualting the needed errata & package counts for these 1000
is very expensive. You can calculate for 100 in a reasonable amount of
time. So the driving query would return the list of systems with just
their id and name for example. This would allow the user to sort by
name. The list tag would then 'clamp' down only the first 100 systems
and would run elaboration on them to fill in the other details for the
100 being displayed (such as calculating the number of needed errata
from cache).
This is really only useful within the UI, and any API call should call
elaborate manually if there are elaborators (when not using a hibernate
query and the additional data is desired). You are correct that the
incorrect change here was removing the attributes needed for sorting
from the driving query.
I would not recommend changing the BaseManager to elaborate it
automatically, as that really should be left to the corresponding list tag.
I hope that makes sense :)
-Justin
_______________________________________________
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
