On Mon, Jul 02, Jan Kupec wrote:
Stefan Hundhammer wrote:
On Friday 29 June 2007 15:14, Jan Kupec wrote:
Here is my proposal of a new libzypp API for various metadata queries. It should be useful for YaST package managers, zypper, YaST online update and maybe others. Pease see attached QueryBuilder.h file and comment on the design and usability.
QueryBuilder is meant to build an sqlite query for libzypp's metadata cache database and to be used by ResolvableQuery::query(QueryBuilder,ProcessingFunctor) function (or other Query class) to do complex resolvable data queries. Result of these queries will be processed by ProcessingFunctor (read on).
The reason to create such an API is to have a convenient API for coding various kinds of user queries, so that apps using libzypp don't have to code the functionality by themselves by traversing the resolvable pool.
That's a nice API for querying resolvables. Will there be a counterpart for querying selectables (which is what the UI needs), too?
Sure! Note the comment in parenthesis after the code example:
IMO Huha is looking for something, the 'UI' will not find here. Neither with the existing query API, nor with Janos proposal. A better integration of Selectables into the Pool. (I tried to describe it as well in an earlier mail: 29 Jun; Re: [yast-devel] Adding missing API to libzypp (or between libzypp andapps) ) A Selectable (and NameKindProxy too) is a container of PoolItems, all of the same kind and name. E.g: ALL known Packages named glibc will be available in the 'NameKindProxy(Package,glibc)'. A 'Selectable(Package,glibc)' will contain at most ONE installed, and all available glibc packages. ;( There is no difference, unless more than one version of a package is installed. In that case there are as many Selectables as there are versions installed. Each Selectable links to only ONE installed but to ALL available versions. Unfortunately we support this (e.g. multiple kernel versions being installed at the same time). If we query for some property (like 'provides glibc = 2.5'), the query usually leads to individual Packages (or PoolItems). Each PoolItem maps one-to-one to a NameKindProxy, but not to a Selectable. That's why we could easily implement a backlink from each PoolItem to it's corresponding NameKindProxy. But not to a Selectable. If the UI would move, and use a Selectable that actually links to ALL known instances of a certain (name,kind), we could start to implement a backlink from each PoolItem to it's coresponding Selectable. That way the UI could immediately benefit from each query zypp provides, because the PoolItem maps to a UI Selectable. -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres YaST Development ma@novell.com SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+ -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org