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

Re: [GSoC] Rewriting tasks.py to exclusively use UDD



On Tue, Jun 30, 2015 at 08:07:12PM +0530, Akshita Jha wrote:
> > I totally rely on you decision here.  The result is important and I do
> > not mind how you would like to implement this.  I do not see any
> > relevant advantage in one of the implementation options - feel free to
> > choose what you consider more simple.
> 
> I think I'll write 3 separate queries for official_packages,
> prospective_packages and new_packages ?

Fine.

> Also, do you think we should modify
> the function blends_query_packages[1] to not query the publications from
> bibref table (as discussed earlier[2]) ?

As far as we have no more reliable source of citations we should take it
as is.

> I have written a UDD query to get all the information for
> blends_prospectivepackages.
> 
> query = "SELECT DISTINCT bp.package, bp.component, bp.homepage, bp.section,
> bp.source,
> bp.vcs_type, bp.vcs_url, bp.vcs_browser,
> bp.changed_by, bp.uploaders, bp.maintainer, bp.license,
> b.dependency, pop.vote, pop.recent, tags.debtags,
> bp.description, bp.long_description,
> screenshot_versions, large_image_urls, small_image_urls
> FROM blends_prospectivepackages bp JOIN blends_dependencies b ON
> b.blend=bp.blend
> LEFT OUTER JOIN popcon pop ON pop.package=bp.package
> LEFT OUTER JOIN (
> SELECT package, array_agg(tag) AS debtags FROM debtags
> WHERE tag NOT LIKE 'implemented-in::%'
> AND tag NOT LIKE 'protocol::%'
> AND tag NOT LIKE '%::TODO'
> AND tag NOT LIKE '%not-yet-tagged%'
> GROUP BY package
> ) tags ON tags.package = bp.package
> LEFT OUTER JOIN (
> SELECT package, array_agg(version)  AS screenshot_versions,
> array_agg(large_image_url) AS large_image_urls,
> array_agg(small_image_url) AS small_image_urls
> FROM screenshots
> GROUP BY package
> ) sshots ON sshots.package = bp.package
> WHERE bp.blend='%s' and b.task='%s'" % (self.blendname, self.task)
> 
> After executing the above query, I get the following:
> 
>         dep.pkg = each_pros[0]
>         dep.component = each_pros[1]
>         dep.pkgstatus = (Depends on dep.component)
>         dep.properties['homepage'] = each_pros[2]
>         dep.properties['section'] = each_pros[3]
>         dep.properties['license'] = each_pros[4]
>         dep.properties['vcs_type'] = each_pros[5]
>         dep.properties['vcs_url'] = each_pros[6]
>         dep.properties['vcs_browser'] = each_pros[7]
>         dep.properties['changed_by'] = each_pros[8]
>         dep.properties['last_uploader'] = each_pros[9]
>         dep.properties['last_uploader_simple'] = (not sure what this is !!)
>         dep.desc = (in various languages)
>         dep.properties['maintainer'] = each_pros[10]
>         dep.responsible = (dep.properties['maintainer']) will be pasrsed to
> get this
>         dep.popcon['vote']   = each_pros[13]
>         dep.popcon['recent'] = each_pros[14]
>         dep.debtags = each_pros[15]
>         dep.desc['en']['short'] = each_pros[16]
>         dep.desc['en']['long'] = each_pros[17]
> 
> However, do blends_prospectivepackages have the below information available
> in UDD where I can query them from ?
> 
>         dep.releases =

Prospective packages were never released (that's why they are prospective ;-)).

>         dep.icon = (Is this small_image_url from screenshots table ?)
>         dep.screenshot_url = (screenshot_url from screenshots table ?)
>         dep.image =
>         dep.screenshots =

Nobody made screenshots for not yet existing packages - so there is no such
information.

> Also, I am assuming the description for blends_prospectivepackages will be
> available only in english

Yes.

> and we do not need to query publications from
> bibref. Am I right ?

No.  The publication information actually *is* available as you can
check and this comes from the vcs import which is more reliable as the
other method (which I tried to explain in our thread about bibref).
Also pkgs in new might have citation information.

> This is just a pseudo code. What I plan do is execute query_pkgs(for
> official packages) ,query_new_pkgs and query_prospective_pkgs; call a
> function GetDepInfo() function which stores all the information in dep
> object for each of the 3 prepared queries. Does this seem alright ?

Sounds good

     Andreas.

-- 
http://fam-tille.de


Reply to: