[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [GSoC] blends-gen-control hints (Was: blends-dev, gsoc 2013)



Hi Emmanouil,

On Fri, Jun 28, 2013 at 01:55:12AM +0300, Emmanouil Kiagias wrote:
> > ...
> > without any alternative (or whatever).  Your suggestion to just join
> > the alternatives behing gecko-mediaplayer would break and you could
> > also find different sequences of alternatives - so I think we somehow
> > need to preserve the content of the tasks files in a clever way.
> 
> 
> Ah, yes I now understand the problem in my idea. So in case we did it this
> way(just wondering) we would need 3 keys(blendname, task, package1) to
> identify the alternative package in order to avoid the problem you
> mention?( instead of having only the package1 for primary key)

Yes, that's the main flaw - the trouble we would run into you wrote
below is another one.

>  The
> > only chance that might safe us from using two tables would be some
> > view that splits up the '|' in the table I mentioned above and adds
> > extra rows for every alternative.  This could require some bit of
> > SQL magic.  But all in all our tables are not really expensive and if
> > you do not know such clever SQL tricks that turn the table above into
> >
> > blend      | task          | package            | dependency |
> > distribution | component
> >
> > -----------+---------------+--------------------+------------+--------------+------------
> > debian-edu | desktop-other | gecko-mediaplayer  | d          | debian
> >   | main
> > debian-edu | desktop-other | mozilla-mplayer    | d          | debian
> >   | main
> > debian-edu | desktop-other | kaffeine-mozilla   | d          | debian
> >   | main
> > debian-edu | desktop-other | mozilla-plugin-vlc | d          | debian
> >   | main
> > debian-edu | desktop-other | totem-mozilla      | d          | debian
> >   | main
> > debian-edu | desktop-other | default-jre        | d          | debian
> >   | main
> > debian-edu | desktop-other | openjdk-6-jre      | d          | debian
> >   | main
> > debian-edu | desktop-other | icedtea6-plugin    | d          | debian
> >   | main
> > ...
> >
> > (which is our current table) we might go with two tables.
> 
> 
> To be honest I don't know such sql tricks, I have never dealt with
> something similar  before, but as they say there is always a first time :-)

PostgreSQL is very powerful and I guess you could do some cool tricks
with functions splitting up the field values and create new rows in a
table valued procedure.  But IMHO that's a very academical exercise
with less prectical relevance.
 
> >  I'm sure
> > there will be a way to create a view to get this but it is error prone
> > and definitely not fast for simply saving some bytes on a hard disk ...
> >
> 
> Yes it should be a way, I will look it up (I am curious to find out how
> this can be done) but as you said it will probably be error prone.

I will never try to stop you from doing some attempt to learn new
tricks. ;-)

> > However, I think we should start with some documentation about the
> > motivation for those two similar tables to make sure people will not
> > stumble upon it in future.
> >
> >
> Yes I agree I will document this tomorrow. Where should I documented it?
> For the beginning I will write a readme file(in some other syntax?)

I'm not really sure.  UDD is close to not documented.  Perhaps it is a
good idea to ask on debian-qa@lists.debian.org using the key "[UDD]" in
the subject line.  This is where UDD issues are discussed.  I personally
started with a README file in udd/sql.  Perhaps it is appropriate to
continue here.

> > I admit I do not understand this paragraph (in exchange to mine which
> > was surely not understandable).
> >
> haha, now that i see it again you're right, it's not understandable. So
> what I mean (I will try to make sense this time) is that:
> In case we only use one (let's say) blend_dependencies table with a column
> like package_s_:
> 
> blend      | task          | package_s_                                |
> dependency | distribution | component
> -----------+---------------+---------------------------------------------------------------------------------------------+------------+--------------+------------
> debian-edu | desktop-other | default-jre | openjdk-6-jre      | d
>      | debian       | main
> debian-edu | desktop-other | icedtea6-plugin                    | d
>        | debian       | main
> 
> then we would not be able to join it with the UDD "packages" table using
> the package_s_ as joining condition. So in that case  with a first query we
> get the package_s_ information (get the alternatives) and with a second
> query(eg like you said in your way with a view) we split the "|"  in the
> above table  into something that can be joined with packages table (in
> order to get the same info we get now with blends-gsoc/sql/blendsd). That's
> why I said "break"(split) my sql into two parts. To be honest I was a
> little thoughtless when I wrote this paragraph, i did not have clear in my
> mind how it could be done but anyway your idea fully covered this part(and
> also made things more clear).

Yes, this is the second flaw of the "single table" approach.

BTW, I just commited and tested the "Section", "Enhances", etc.  keys
and will implemented in production UDD in a couple of hours.  The
stumbling stone was (as usual) totally unconnected with my change[1].
The whole update process of tasks was broken by some change and I needed
to fix this first.

Kind regards

        Andreas.

[1] https://lists.debian.org/debian-devel/2013/06/msg00823.html

-- 
http://fam-tille.de


Reply to: