Re: [Spacewalk-devel] List of installable packages: API vs. Web UI
On 11/08/2012 12:18 PM, Johannes Renner wrote: On 11/05/2012 12:03 PM, Tomas Lestach wrote: ... If there's a bug in the API call, we of course fix it. But we try to keep the current API interface as is. Spacewalk users have their scripts using our API calls and we do not want to break the scripts by renaming/deleting existing API calls. (Introducing of new sensefull APIs is always good. :) So, it is important that the API behaves according to its name. It the name and behavior do not match, we fix the behavior according to the name and can introduce a new API in case the behavior of the original API was helpfull. However, internal naming has lower priority, because the users do not come into contact with it, so it cannot be confusing for them. (But we of course try to keep the naming sensefull as well.) Ok, I might come up with a patch these days, fixing the existing API call so it behaves like its name is suggesting + maybe add a new call to provide the previous behavior in addition to that. Thanks for the explanations, Johannes Ok, here we go: The first patch should fix the query for the existing API call so that actually only the very latest versions of packages will be returned, as the name of the function suggests. (Note that the query might have been working for you correctly before, but only in case all of packages and updates are provided through one single channel, I guess). Further, the query is internally renamed like this (in Package_queries.xml): system_latest_all_available_packages - system_latest_available_packages The second patch adds a new API call to list all versions and releases of packages that can be installed to a given system: system.list_all_installable_packages(key, sid) Unfortunately the previous query could not be reused, since it didn't actually return all of the versions and releases of a package (as noted above). It rather returned only the max EVR version of each package in every channel the system is subscribed to. This might have lead to correct behavior for list_latest, but only in case all packages are provided through _one_ single channel. So the second patch also contains a new query to handle the list_all_... case. Regards, Johannes -- SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer From 84295bbb50bf32bfbec425d3aca516eeb8276d85 Mon Sep 17 00:00:00 2001 From: Johannes Renner jren...@suse.de Date: Wed, 21 Nov 2012 18:21:20 +0100 Subject: [PATCH] Fix query for API call system.listLatestInstallablePackages --- .../common/db/datasource/xml/Package_queries.xml | 33 +++- .../redhat/rhn/manager/system/SystemManager.java |2 +- 2 files changed, 20 insertions(+), 15 deletions(-) diff --git a/java/code/src/com/redhat/rhn/common/db/datasource/xml/Package_queries.xml b/java/code/src/com/redhat/rhn/common/db/datasource/xml/Package_queries.xml index 44bc39d..38e7f4b 100644 --- a/java/code/src/com/redhat/rhn/common/db/datasource/xml/Package_queries.xml +++ b/java/code/src/com/redhat/rhn/common/db/datasource/xml/Package_queries.xml @@ -6,20 +6,19 @@ /query /callable-mode -mode name=system_latest_all_available_packages +mode name=system_latest_available_packages query params=sid SELECT pn.name AS name, -full_list.id AS id, +pkg.id AS id, NVL((full_list.evr).version, ' ') AS version, NVL((full_list.evr).release, ' ') AS release, NVL((full_list.evr).epoch, ' ') AS epoch, NVL(full_list.arch_label, ' ') AS arch_label FROM ( SELECT p.name_id name_id, - p.id, - p.evr_id, max(pe.evr) evr, + pa.id as arch_id, pa.label as arch_label FROM rhnPackageArch PA, rhnPackageEVR PE, rhnPackage P, rhnChannelNewestPackage CNP, rhnServerChannel SC @@ -28,17 +27,23 @@ SELECT AND cnp.package_id = p.id AND p.evr_id = pe.id AND p.package_arch_id = pa.id - GROUP BY p.name_id, p.id, p.evr_id, pa.label + GROUP BY p.name_id, pa.label, pa.id ) full_list, - rhnPackageName pn - WHERE full_list.name_id = pn.id - AND NOT EXISTS (SELECT 1 - FROM rhnServerPackage SP, rhnPackageEVR PE2 - WHERE SP.server_id = :sid - AND SP.name_id = full_list.name_id - AND SP.evr_id = PE2.id - AND PE2.evr gt;= full_list.evr) -ORDER BY UPPER(pn.name), full_list.evr + rhnPackage pkg + join rhnPackageName pn on pkg.name_id = pn.id + join rhnPackageEVR pevr on pkg.evr_id = pevr.id + join rhnChannelPackage CP on CP.package_id = pkg.id + join rhnServerChannel SC on SC.channel_id = CP.channel_id + WHERE full_list.name_id = pkg.name_id + AND full_list.evr = pevr.evr + AND full_list.arch_id = pkg.package_arch_id +
Re: [Spacewalk-devel] List of installable packages: API vs. Web UI
On 11/05/2012 12:03 PM, Tomas Lestach wrote: ... If there's a bug in the API call, we of course fix it. But we try to keep the current API interface as is. Spacewalk users have their scripts using our API calls and we do not want to break the scripts by renaming/deleting existing API calls. (Introducing of new sensefull APIs is always good. :) So, it is important that the API behaves according to its name. It the name and behavior do not match, we fix the behavior according to the name and can introduce a new API in case the behavior of the original API was helpfull. However, internal naming has lower priority, because the users do not come into contact with it, so it cannot be confusing for them. (But we of course try to keep the naming sensefull as well.) Ok, I might come up with a patch these days, fixing the existing API call so it behaves like its name is suggesting + maybe add a new call to provide the previous behavior in addition to that. Thanks for the explanations, 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
Re: [Spacewalk-devel] List of installable packages: API vs. Web UI
On Friday 02 of November 2012 12:03:28 Johannes Renner wrote: On 11/01/2012 01:59 PM, Tomas Lestach wrote: On Wednesday 31 of October 2012 15:00:48 Johannes Renner wrote: Hello, We found that the list of installable packages for a given system differs if you either ask the API (via system.listLatestInstallablePackages) or if you go to the Web UI (Systems - [choose a system] - Software - Packages - Install). After looking into it, I found there is two different queries used for this (both to be found in Package_queries.xml): 1. system_latest_all_available_packages (API) 2. system_available_packages (Web UI) My questions: - Query (1.) seems to return all available versions of a package, which means 'all' rather than 'latest'? I think we could have two separate API calls, one for 'latest' and one for 'all', but 'latest_all'? Right, the naming is strange. - Shouldn't we use the same query for API and Web UI in order to get the same results here? I'd say we do not want to get the same results. As people are used to the WebUI, they may select and install any version of an available package. I wouldn't change that. If an API is called listLatestInstallablePackages, it shall definitelly return list of *latest* installable packages. But what we could do is we can introduce a listAllInstallablePackages/listAvailableInstallablePackages API, that could reuse the WebUI query. :-) Haha, yes, good idea ;-) Hello Johannes, So, IIUC this is the situation summarized: The current API call needs to continue to exist as it is, the method declaration - yes but you agree that the naming of the API call, as well as the query name, is strange. yes To fix this, we would actually rename the existing API call to something more 'correct', like e.g. 'listAllInstallablePackages'. Further we could change the semantics of 'listLatestInstallablePackages' in a way that it reuses the WebUI query and thus will return the same results as the WebUI itself. The only problem is that we are most likely not supposed to change the semantics of an existing API call, right? Is this true, even if we considered such 'unexpected' behavior as a bug? Regards, Johannes If there's a bug in the API call, we of course fix it. But we try to keep the current API interface as is. Spacewalk users have their scripts using our API calls and we do not want to break the scripts by renaming/deleting existing API calls. (Introducing of new sensefull APIs is always good. :) So, it is important that the API behaves according to its name. It the name and behavior do not match, we fix the behavior according to the name and can introduce a new API in case the behavior of the original API was helpfull. However, internal naming has lower priority, because the users do not come into contact with it, so it cannot be confusing for them. (But we of course try to keep the naming sensefull as well.) Regards, -- Tomas Lestach RHN Satellite Engineering ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] List of installable packages: API vs. Web UI
On 11/01/2012 01:59 PM, Tomas Lestach wrote: On Wednesday 31 of October 2012 15:00:48 Johannes Renner wrote: Hello, We found that the list of installable packages for a given system differs if you either ask the API (via system.listLatestInstallablePackages) or if you go to the Web UI (Systems - [choose a system] - Software - Packages - Install). After looking into it, I found there is two different queries used for this (both to be found in Package_queries.xml): 1. system_latest_all_available_packages (API) 2. system_available_packages (Web UI) My questions: - Query (1.) seems to return all available versions of a package, which means 'all' rather than 'latest'? I think we could have two separate API calls, one for 'latest' and one for 'all', but 'latest_all'? Right, the naming is strange. - Shouldn't we use the same query for API and Web UI in order to get the same results here? I'd say we do not want to get the same results. As people are used to the WebUI, they may select and install any version of an available package. I wouldn't change that. If an API is called listLatestInstallablePackages, it shall definitelly return list of *latest* installable packages. But what we could do is we can introduce a listAllInstallablePackages/listAvailableInstallablePackages API, that could reuse the WebUI query. :-) Haha, yes, good idea ;-) So, IIUC this is the situation summarized: The current API call needs to continue to exist as it is, but you agree that the naming of the API call, as well as the query name, is strange. To fix this, we would actually rename the existing API call to something more 'correct', like e.g. 'listAllInstallablePackages'. Further we could change the semantics of 'listLatestInstallablePackages' in a way that it reuses the WebUI query and thus will return the same results as the WebUI itself. The only problem is that we are most likely not supposed to change the semantics of an existing API call, right? Is this true, even if we considered such 'unexpected' behavior as a bug? Regards, 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
Re: [Spacewalk-devel] List of installable packages: API vs. Web UI
On Wednesday 31 of October 2012 15:00:48 Johannes Renner wrote: Hello, We found that the list of installable packages for a given system differs if you either ask the API (via system.listLatestInstallablePackages) or if you go to the Web UI (Systems - [choose a system] - Software - Packages - Install). After looking into it, I found there is two different queries used for this (both to be found in Package_queries.xml): 1. system_latest_all_available_packages (API) 2. system_available_packages (Web UI) My questions: - Query (1.) seems to return all available versions of a package, which means 'all' rather than 'latest'? I think we could have two separate API calls, one for 'latest' and one for 'all', but 'latest_all'? Right, the naming is strange. - Shouldn't we use the same query for API and Web UI in order to get the same results here? I'd say we do not want to get the same results. As people are used to the WebUI, they may select and install any version of an available package. I wouldn't change that. If an API is called listLatestInstallablePackages, it shall definitelly return list of *latest* installable packages. But what we could do is we can introduce a listAllInstallablePackages/listAvailableInstallablePackages API, that could reuse the WebUI query. :-) Regards, -- Tomas Lestach RHN Satellite Engineering Thanks, Johannes ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] List of installable packages: API vs. Web UI
Hello, We found that the list of installable packages for a given system differs if you either ask the API (via system.listLatestInstallablePackages) or if you go to the Web UI (Systems - [choose a system] - Software - Packages - Install). After looking into it, I found there is two different queries used for this (both to be found in Package_queries.xml): 1. system_latest_all_available_packages (API) 2. system_available_packages (Web UI) My questions: - Query (1.) seems to return all available versions of a package, which means 'all' rather than 'latest'? I think we could have two separate API calls, one for 'latest' and one for 'all', but 'latest_all'? - Shouldn't we use the same query for API and Web UI in order to get the same results here? 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
