Re: UDD data -> MySQL - Was: Re: Archiving UDD data : FLOSSMole ?
On Tue, Jun 16, 2009 at 11:22:10PM +0200, Olivier Berger wrote: > I think it depends the kind of analysis people might want to do for > their research in mining the Debian metadata that would be archived in > FLOSSMole, maybe these package versions wouldn't be needed, so strings > without the full arithmetics of versions would be enough ? > > In any case, the first idea is to archive data so that it's there for > history, I suppose, then the users will complain eventually, and we > shall see ;) Exactly. I see no problem in archiving it to MySQL, injecting versions as string. That would just mean that you can't run the exactly same query you run now, but you can still re-inject historical versions elsewhere and/or use some MySQL extensions to obtain the same effect. Cheers. -- Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7 z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/ Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime signature.asc Description: Digital signature
Re: UDD data -> MySQL - Was: Re: Archiving UDD data : FLOSSMole ?
Le mardi 16 juin 2009 à 12:50 +0200, Andreas Tille a écrit : > On Tue, Jun 16, 2009 at 09:49:27AM +0200, Stefano Zacchiroli wrote: > > UDD has some parts that are Postgres specific, in particular it uses > > the Postgres extension mechanism to internalize Debian version > > comparison so that it can be exploited in queries. In the beginning, > > the internalization was done only as an extension function, it might > > be that now there is even a custom data type where you can use "<" and > > such, but I'm not sure about that (redirect to Lucas). > > I can confirm that there is a new data type debversion: > SNIP > which is probably hard to reimplement in MySQL. There was a thread > here on this list about this data type and its implementation. > Thanks for these comments. That's what I had also indentified as PostGres dependant when we discussed the subject on the ossmole-discuss list. > > You just need to pay attention (and maybe do some tests) that, > > migrating away from Postgres, you might loose the ability to reuse the > > same queries which you can currently use with udd.d.o. > > IMHO it is not a good idea to try to port UDD to a different > database engine. > I think it depends the kind of analysis people might want to do for their research in mining the Debian metadata that would be archived in FLOSSMole, maybe these package versions wouldn't be needed, so strings without the full arithmetics of versions would be enough ? In any case, the first idea is to archive data so that it's there for history, I suppose, then the users will complain eventually, and we shall see ;) Thanks again. Best regards, -- Olivier BERGER http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC Ingénieur Recherche - Dept INF Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France) -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: UDD data -> MySQL - Was: Re: Archiving UDD data : FLOSSMole ?
On Tue, Jun 16, 2009 at 09:49:27AM +0200, Stefano Zacchiroli wrote: > UDD has some parts that are Postgres specific, in particular it uses > the Postgres extension mechanism to internalize Debian version > comparison so that it can be exploited in queries. In the beginning, > the internalization was done only as an extension function, it might > be that now there is even a custom data type where you can use "<" and > such, but I'm not sure about that (redirect to Lucas). I can confirm that there is a new data type debversion: udd=> \d packages Table "public.packages" Column|Type| Modifiers -++--- package | text | not null version | debversion | not null architecture| text | not null maintainer | text | description | text | long_description| text | source | text | source_version | debversion | ... which is probably hard to reimplement in MySQL. There was a thread here on this list about this data type and its implementation. > You just need to pay attention (and maybe do some tests) that, > migrating away from Postgres, you might loose the ability to reuse the > same queries which you can currently use with udd.d.o. IMHO it is not a good idea to try to port UDD to a different database engine. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: UDD data -> MySQL - Was: Re: Archiving UDD data : FLOSSMole ?
On Wed, Jun 10, 2009 at 05:59:21PM +0200, Olivier Berger wrote: > Actually, something obvious seems to render things a bit difficult at > first sight : UDD is in PostGres, and FLOSSMole uses MySQL. > > We're discussing some options on the ossmole-discuss list to overcome > this difficulty. > > My advice is to import in PG on a Debian system with the required > dependencies, create views to be able to convert non standard types to > standard ones, then dump again to SQL, and import to MySQL... any > comments ? UDD has some parts that are Postgres specific, in particular it uses the Postgres extension mechanism to internalize Debian version comparison so that it can be exploited in queries. In the beginning, the internalization was done only as an extension function, it might be that now there is even a custom data type where you can use "<" and such, but I'm not sure about that (redirect to Lucas). You just need to pay attention (and maybe do some tests) that, migrating away from Postgres, you might loose the ability to reuse the same queries which you can currently use with udd.d.o. Cheers. -- Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7 z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/ Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime signature.asc Description: Digital signature