Mailinglist Archive: yast-devel (85 mails)

< Previous Next >
Re: [yast-devel] [RFC] QueryBuilder and (Resolvable)Query
  • From: Michael Andres <ma@xxxxxxx>
  • Date: Mon, 2 Jul 2007 23:47:27 +0200
  • Message-id: <20070702214727.GA19621@xxxxxxx>
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@xxxxxxxxxx
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@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups