Re: [Spacewalk-devel] [PATCH] Query not elaborated?
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:///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
Re: [Spacewalk-devel] [PATCH] remove MAC address from profile list
Hi Uwe, Thanks for noticing that. I agree that it makes no sense. That was an unintended side-effect of the MAC address feature. I'll look into fixing it. -Stephen On 08/13/2012 09:22 AM, Uwe Gansert wrote: Hi, I was wondering if the MAC address in the profile list: https://my.server.de/rhn/systems/details/virtualization/ProvisionVirtualizationWizard.do?sid=110001 makes sense. I know there is a new feature where you can configure the MAC address for a new virtual machine but in the list of profiles, that makes no sense from my point of view. Do I overlook something? ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] [PATCH] remove MAC address from profile list
Hi, I was wondering if the MAC address in the profile list: https://my.server.de/rhn/systems/details/virtualization/ProvisionVirtualizationWizard.do?sid=110001 makes sense. I know there is a new feature where you can configure the MAC address for a new virtual machine but in the list of profiles, that makes no sense from my point of view. Do I overlook something? -- ciao, Uwe Gansert SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer Home: http://www.suse.de/~ug - Blog: http://suse.gansert.net >From 30e4bd5d3f2f9072f4696ccfb7bed0d9517f3584 Mon Sep 17 00:00:00 2001 From: Uwe Gansert Date: Mon, 13 Aug 2012 15:18:22 +0200 Subject: [PATCH] removed MAC address from profile list --- .../frontend/strings/jsp/StringResource_en_US.xml |8 .../details/virtualization/provision/first.jsp |3 +-- 2 files changed, 1 insertions(+), 10 deletions(-) diff --git a/java/code/src/com/redhat/rhn/frontend/strings/jsp/StringResource_en_US.xml b/java/code/src/com/redhat/rhn/frontend/strings/jsp/StringResource_en_US.xml index c3476b3..956ed9a 100644 --- a/java/code/src/com/redhat/rhn/frontend/strings/jsp/StringResource_en_US.xml +++ b/java/code/src/com/redhat/rhn/frontend/strings/jsp/StringResource_en_US.xml @@ -16229,14 +16229,6 @@ the Acti - -Mac Address - -/rhn/systems/details/virtualization/ProvisionVirtualizationWizard.do - - - - Profiles that are not @@PRODUCT_NAME@@-managed are not guaranteed to register systems to @@PRODUCT_NAME@@ after kickstart. You may wish to review these kickstarts (click on the profile name to do so) to confirm whether or not your system will reappear in the @@PRODUCT_NAME@@ system list after kickstart. diff --git a/java/code/webapp/WEB-INF/pages/systems/details/virtualization/provision/first.jsp b/java/code/webapp/WEB-INF/pages/systems/details/virtualization/provision/first.jsp index 0494510..f821cf2 100644 --- a/java/code/webapp/WEB-INF/pages/systems/details/virtualization/provision/first.jsp +++ b/java/code/webapp/WEB-INF/pages/systems/details/virtualization/provision/first.jsp @@ -43,8 +43,7 @@ function setStep(stepName) { - - + -- 1.7.7 ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Query not elaborated?
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:///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 -- SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
