Files
@ af7b367f6b5a
Branch filter:
Location: kallithea/docs/usage/statistics.rst - annotation
af7b367f6b5a
1.2 KiB
text/prs.fallenstein.rst
db: introduce constraint ensuring no duplicate (reviewer, pullrequest) combinations
A reviewer should only be added once to a review.
Previously, this was not ensured by the database itself, although that the
controller would try to not add duplicate reviewers. But there was no hard
guarantee: e.g. simultaneous adding of the same reviewer to the same review
by a review owner and admin, a framework bug that sends the same request
twice, ... could still trigger duplicate addition. Additionally, code
changes (e.g. a new API) could introduce bugs at the controller level.
Existing production databases were found to contain such duplicate entries.
Nevertheless, as the code displaying reviewers in a pull request filtered
out duplicates, this never showed in the UI, and never was a 'real' problem.
Add a UniqueConstraint in the database to prevent such entries, with a
database migration step that will first find and remove existing duplicates.
A reviewer should only be added once to a review.
Previously, this was not ensured by the database itself, although that the
controller would try to not add duplicate reviewers. But there was no hard
guarantee: e.g. simultaneous adding of the same reviewer to the same review
by a review owner and admin, a framework bug that sends the same request
twice, ... could still trigger duplicate addition. Additionally, code
changes (e.g. a new API) could introduce bugs at the controller level.
Existing production databases were found to contain such duplicate entries.
Nevertheless, as the code displaying reviewers in a pull request filtered
out duplicates, this never showed in the UI, and never was a 'real' problem.
Add a UniqueConstraint in the database to prevent such entries, with a
database migration step that will first find and remove existing duplicates.
bbd499c7b55e bbd499c7b55e ac7e43325817 ac7e43325817 ac7e43325817 bbd499c7b55e 5ae8e644aa88 ac7e43325817 ac7e43325817 ac7e43325817 bbd499c7b55e ac7e43325817 ac7e43325817 ac7e43325817 ac7e43325817 ac7e43325817 bbd499c7b55e ac7e43325817 ac7e43325817 ac7e43325817 bbd499c7b55e ac7e43325817 ac7e43325817 ac7e43325817 bbd499c7b55e ac7e43325817 bbd499c7b55e ac7e43325817 ac7e43325817 ac7e43325817 ac7e43325817 | .. _statistics:
=====================
Repository statistics
=====================
Kallithea has a *repository statistics* feature, disabled by default. When
enabled, the amount of commits per committer is visualized in a timeline. This
feature can be enabled using the ``Enable statistics`` checkbox on the
repository ``Settings`` page.
The statistics system makes heavy demands on the server resources, so
in order to keep a balance between usability and performance, statistics are
cached inside the database and gathered incrementally.
When Celery is disabled:
On each first visit to the summary page a set of 250 commits are parsed and
added to the statistics cache. This incremental gathering also happens on each
visit to the statistics page, until all commits are fetched.
Statistics are kept cached until additional commits are added to the
repository. In such a case Kallithea will only fetch the new commits when
updating its statistics cache.
When Celery is enabled:
On the first visit to the summary page, Kallithea will create tasks that will
execute on Celery workers. These tasks will gather all of the statistics until
all commits are parsed. Each task parses 250 commits, then launches a new
task.
|