community-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sebb (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COMDEV-146) countaccounts.py can miss a days worth of new accounts
Date Mon, 20 Jul 2015 22:18:04 GMT

    [ https://issues.apache.org/jira/browse/COMDEV-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14634160#comment-14634160
] 

Sebb commented on COMDEV-146:
-----------------------------

URL: http://svn.apache.org/r1692026
Log:
COMDEV-146 - countaccounts.py can miss a days worth of new accounts
TODO fix up historic values

Modified:
    comdev/projects.apache.org/scripts/cronjobs/countaccounts.py

> countaccounts.py can miss a days worth of new accounts
> ------------------------------------------------------
>
>                 Key: COMDEV-146
>                 URL: https://issues.apache.org/jira/browse/COMDEV-146
>             Project: Community Development
>          Issue Type: Bug
>          Components: Projects New
>            Reporter: Sebb
>
> The script countaccounts.py is currently run once a day at midnight (or just after).

> It currently only counts entries for the current month, so will not count entries that
were added after it has already run on the last day of the month. (However, entries for the
1st day of the month that occur later in the day will be picked up by a subsequent run.)
> [It also fetches the time twice, which could result in odd behaviour]
> It's not possible to ensure that it runs just before the day changes (e.g. if cron tries
to start it at 23:59 it may actually start after midnight).
> It looks as though it may be necessary to have the first run occur just after midnight
in order to create the initial empty entry.
> One way round the problem would be to check for day one of a month.
> If so, then subtract a full day and check additionally for the previous month.
> Another approach would be to always add up the counts for each month.
> However, this would also record subsequent deletions.  Also care would need to be taken
to ensure that historic entries were not deleted. Perhaps check if there is an existing entry,
and only update it if the new count is higher?
> Note that the current data is inaccurate because of the timing issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message