Hello Andreas,
On Thu, Jun 27, 2013 at 6:20 PM, Andreas Tille <[email protected]> wrote: > > > I am not quite sure I unsterstood this case. Can you give me an example? > > I'm looking at debian-edu/tasks/desktop-other. This has: > > Depends: gecko-mediaplayer | mozilla-mplayer | kaffeine-mozilla | > mozilla-plugin-vlc | totem-mozilla > > Recommends: default-jre | openjdk-6-jre, icedtea6-plugin > > I would turn this into > > blend | task | package_s_ > | dependency | distribution > | component > > -----------+---------------+---------------------------------------------------------------------------------------------+------------+--------------+------------ > debian-edu | desktop-other | gecko-mediaplayer | mozilla-mplayer | > kaffeine-mozilla | mozilla-plugin-vlc | totem-mozilla | d | debian > | main > debian-edu | desktop-other | default-jre | openjdk-6-jre > | d | debian | > main > debian-edu | desktop-other | icedtea6-plugin > | d | debian | > main > ... > > > So you can take over 1:1 from package_s_ (a suggestion more reasonable > column name would be welcome as well as a decision whether *this* table > should be named blends_dependencies and the other currently existing > table rather blends_packages). > > Your initial suggetsion would fail say for debian-multimedia where > it might be perfectly possible to have some > > Depends: gecko-mediaplayer > > 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) 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 :-) > 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. > 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 tempted to just throw into the table what is found > > > between the ',' in a Depends line. I'll keep on thinking about this, > > > thought. > > > > > This can also be a solution for the moment, I will just have to break my > > query for blend-dependencies into two parts(because that way I will not > be > > able to full outer join "blend_dependencies" with the "packages" table on > > "package" field, but that's ok, it can done into two parts and get the > same > > results as we get now). > > 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). I will start from documenting the motivation about the extra table(two similar tables). Kind regards Emmanouil
