overall, a nice branch. I have though a few qestions regarding the
filtering of inactive projects for the karma display, so I'm marking
the MP as "needs information".
> === modified file 'lib/lp/registry/model/person.py'
> --- lib/lp/registry/model/person.py 2010-04-19 21:16:12 +0000
> +++ lib/lp/registry/model/person.py 2010-04-22 18:05:27 +0000
> @@ -850,12 +850,16 @@
> def getProjectsAndCategoriesContributedTo(self, limit=5):
> """See `IPerson`."""
> contributions = []
> - results = self._getProjectsWithTheMostKarma(limit=limit)
> - for pillar_name, karma in results:
> + # Pillars names have no concept of active. Extra pillars names are
> + # requested because deactivated pillars will be filtered out.
> + extra_limit = limit + 5
> + results = self._getProjectsWithTheMostKarma(limit=extra_limit)
> + for pillar_name, karma in results[:limit]:
While you retrieve 5 extra items calling _getProjectsWithTheMostKarma(),
you remove these extra items here ;)
But: Did you consider to change the SQL query in the method
_getProjectsWithTheMostKarma() itself so that only activ projects
are returned (if necessary, using an optional method parameter
"active_only=False")?
While adding five extra items to the result set looks reasonable,
there is the (admittedly largely theoretical) situation that
the result set contains more than five inactive projects, so that
the length of the "effective" list is shorter than expected.
And I would prefer it anyway to do the filtering in
_getProjectsWithTheMostKarma(), even if it would be too cumbersome
to implement in SQL.
Hi Curtis,
overall, a nice branch. I have though a few qestions regarding the
filtering of inactive projects for the karma display, so I'm marking
the MP as "needs information".
> === modified file 'lib/lp/ registry/ model/person. py' registry/ model/person. py 2010-04-19 21:16:12 +0000 registry/ model/person. py 2010-04-22 18:05:27 +0000 ategoriesContri butedTo( self, limit=5): tsWithTheMostKa rma(limit= limit) tsWithTheMostKa rma(limit= extra_limit)
> --- lib/lp/
> +++ lib/lp/
> @@ -850,12 +850,16 @@
> def getProjectsAndC
> """See `IPerson`."""
> contributions = []
> - results = self._getProjec
> - for pillar_name, karma in results:
> + # Pillars names have no concept of active. Extra pillars names are
> + # requested because deactivated pillars will be filtered out.
> + extra_limit = limit + 5
> + results = self._getProjec
> + for pillar_name, karma in results[:limit]:
While you retrieve 5 extra items calling _getProjectsWit hTheMostKarma( ),
you remove these extra items here ;)
> pillar = getUtility( IPillarNameSet) .getByName( pillar_ name) append( butedCategories (pillar) }) append( butedCategories (pillar) })
> - contributions.
> - {'project': pillar,
> - 'categories': self._getContri
> + if pillar.active:
> + contributions.
> + {'project': pillar,
> + 'categories': self._getContri
> return contributions
I think that should be
return contributions[ :limit]
combined with a loop over the full result set.
But: Did you consider to change the SQL query in the method hTheMostKarma( ) itself so that only activ projects only=False" )?
_getProjectsWit
are returned (if necessary, using an optional method parameter
"active_
While adding five extra items to the result set looks reasonable,
there is the (admittedly largely theoretical) situation that
the result set contains more than five inactive projects, so that
the length of the "effective" list is shorter than expected.
And I would prefer it anyway to do the filtering in hTheMostKarma( ), even if it would be too cumbersome
_getProjectsWit
to implement in SQL.
[...]
> === modified file 'lib/lp/ registry/ tests/test_ person. py' registry/ tests/test_ person. py 2010-02-11 19:26:26 +0000 registry/ tests/test_ person. py 2010-04-22 18:05:27 +0000
> --- lib/lp/
> +++ lib/lp/
[...]
> @@ -597,5 +601,103 @@ (TestCaseWithFa ctory): nalLayer nKarma, self).setUp() makePerson( ) makeProduct( name='aa' ) makeProduct( name='bb' ) makeProduct( name='cc' ) IKarmaCacheMana ger) Cache( Cache( Cache( (self, person, product, category_ name_values) : commit( ) stores( 'karmacacheupda ter') name_values:
> assignee=self.user)
>
>
> +class TestPersonKarma
> +
> + layer = DatabaseFunctio
> +
> + def setUp(self):
> + super(TestPerso
> + self.person = self.factory.
> + a_product = self.factory.
> + b_product = self.factory.
> + self.c_product = self.factory.
> + self.cache_manager = getUtility(
> + self._makeKarma
> + self.person, a_product, [('bugs', 10)])
> + self._makeKarma
> + self.person, b_product, [('answers', 50)])
> + self._makeKarma
> + self.person, self.c_product, [('code', 100), (('bugs', 50))])
> +
> + def _makeKarmaCache
> + """Create a KarmaCache entry with the given arguments.
> +
> + In order to create the KarmaCache record we must switch to the DB
> + user 'karma'. This requires a commit and invalidates the product
> + instance.
> + """
> + transaction.
> + reconnect_
> + total = 0
> + # Insert category total for person and project.
> + for category_name_value in category_
> + category_name, value = category_name_value
Just an aesthetical remark, but I would prefer a simple
for category_name, value in category_ name_values: