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 ?
> Also, do you think we should modify
> the function blends_query_packages to not query the publications from
> bibref table (as discussed earlier) ?
As far as we have no more reliable source of citations we should take it
> I have written a UDD query to get all the information for
> query = "SELECT DISTINCT bp.package, bp.component, bp.homepage, bp.section,
> 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
> 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
> dep.component = each_pros
> dep.pkgstatus = (Depends on dep.component)
> dep.properties['homepage'] = each_pros
> dep.properties['section'] = each_pros
> dep.properties['license'] = each_pros
> dep.properties['vcs_type'] = each_pros
> dep.properties['vcs_url'] = each_pros
> dep.properties['vcs_browser'] = each_pros
> dep.properties['changed_by'] = each_pros
> dep.properties['last_uploader'] = each_pros
> dep.properties['last_uploader_simple'] = (not sure what this is !!)
> dep.desc = (in various languages)
> dep.properties['maintainer'] = each_pros
> dep.responsible = (dep.properties['maintainer']) will be pasrsed to
> get this
> dep.popcon['vote'] = each_pros
> dep.popcon['recent'] = each_pros
> dep.debtags = each_pros
> dep.desc['en']['short'] = each_pros
> dep.desc['en']['long'] = each_pros
> 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
> Also, I am assuming the description for blends_prospectivepackages will be
> available only in english
> 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 ?