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 [email protected] 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
