Apology accepted - sometimes it’s tricky to handle those curve-balls. In any case, there are some lessons here…
···
On 12 July 2018 at 13:51, Morten Olav Hansen morten@dhis2.org wrote:
Hi Calle
I have only been aware of this bug for a few days (when it hit us in Lao), and then we have both release and summer holidays going on. I agree the response is not ideal, but its not the easiest time for fixing bug issues.
We are working hard on fixing this now (it might take 1-2 days), and at that time we will recommend that everyone updates their 229 and 230 instances (I will leave that up to Stian when he is ready)
This was a design issue, and they are not that easy to fix (without causing havoc internally), but hopefully we have learned from this and we won’t name domain tables analytics* anymore.
–
–
Morten Olav Hansen
Senior Engineer, DHIS 2
Team Integration Lead
University of Oslo
http://www.dhis2.org
On Thu, Jul 12, 2018 at 6:33 PM, Calle Hedberg calle.hedberg@gmail.com wrote:
Hi
I’m glad it’s being addressed - but I am less happy to hear you are aware of it but haven’t said anything to the community… These type of bugs causes havoc, and waste a lot of time for users affected while they try to figure out what’s gone wrong.
There are two major lessons here:
Firstly, to stick to a standard and manageable naming convention for both tables and fields (and interfaces).
Secondly, to inform the user community promptly when you become aware of major, “showstopper”, bugs.
Best regards
calle
On 12 July 2018 at 13:15, Morten Olav Hansen morten@dhis2.org wrote:
Ok, thanks Stian (no need to work on this then Viet)
(knut, using pg_dump we normally filter away analytic* which means no period boundaries…)
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp
–
Calle Hedberg
46D Alma Road, 7700 Rosebank, SOUTH AFRICA
Tel/fax (home): +27-21-685-6472
Cell: +27-82-853-5352
Iridium SatPhone: +8816-315-19119
Email: calle.hedberg@gmail.com
Skype: calle_hedberg
–
Morten Olav Hansen
Senior Engineer, DHIS 2
University of Oslo
http://www.dhis2.org
On Thu, Jul 12, 2018 at 6:14 PM, Stian Sandvold stian@dhis2.org wrote:
I have started the work on renaming the table. I will update this thread as soon as I make progress.
On Thu, Jul 12, 2018 at 12:17 PM, Morten Olav Hansen morten@dhis2.org wrote:
Hi Knut
I mean the main issue the thread was about… using maintenance => clear analytic tables, it will delete analytics* which includes the analytical boundaries.
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp
–
Software developer, DHIS2
Stian Sandvold
University of Oslo
http://www.dhis2.org
–
Morten Olav Hansen
Senior Engineer, DHIS 2
University of Oslo
http://www.dhis2.org
On Thu, Jul 12, 2018 at 5:11 PM, Knut Staring knutst@gmail.com wrote:
Hi Morten, sorry but which functionality are you suggesting should not be used? What do you mean by manually deleting?
Thanks,
Knut
On Thu, Jul 12, 2018, 4:23 PM Morten Olav Hansen morten@dhis2.org wrote:
Hi Calle
We are aware of this issue (actually it caused a problem with us in Lao), for now… I would also say don’t use this functionality, its better to manually delete the analytics_* tables if you need it. We will rename that table soon we hope, and that should fix it (this also causes potential issues with your backups…)
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp
–
Morten Olav Hansen
Senior Engineer, DHIS 2
University of Oslo
http://www.dhis2.org
On Thu, Jul 12, 2018 at 3:58 PM, Calle Hedberg calle.hedberg@gmail.com wrote:
Bob,
No response/action on the JIRA bug report yet - I guess most developers are on leave (wonderful summer here in Norway this year).
Otherwise I agree, the name of that table does not fit the general naming convention as far as I can see. It would make more sense to call it e.g. “programindicator_periodboundary”. The name then provides an intuitive description of the content and it sorts together with the group of programindicator tables.
Regards
calle
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp
On 12 July 2018 at 08:57, Bob Jolliffe bobjolliffe@gmail.com wrote:
Thats nasty alright. I guess using “-T anlytics_*” instead would
help. But there are so many backup scripts out there broken by this
that it will be better to rename the table.
On 11 July 2018 at 22:39, Calle Hedberg calle.hedberg@gmail.com wrote:
Hi
For as long as I can remember, we have used the standard parameter "-T
analytics*" when dumping a DHIS2 database into e.g. a backup or similar.
The purpose of the parameter was to exclude all analytics tables from the
dump, since it is significantly faster to restore a dump without analytics
tables and then run analytics to re-create them (due to the use of
multi-threading), compared to dumping and restoring a database instance with
all the analytics table (restore is NOT using multi-threading).
For some reason, in 2.29 a new table that stores periodboundary data for
Program Indicators was called “analyticsperiodboundary” - which means the
standard pg_dump parameter will leave that table behind together with all
other “analytics*” tables.
Furthermore, the routine called “Clear Analytics Tables” found under Data
Administration → Maintenance is as before deleting all tables named
Analytics* - THE PROBLEM IS THAT IT ALSO DELETES THE NEW
ANALYTICSPERIODBOUNDARY TABLE (same in both 2.29 and 2.30)
Which will crash your system in the sense that you won’t see any program
indicator data in dashboards etc.
The “analyticsperiodboundary” table will be re-created and re-populated with
DEFAULT (boundless) Program Indicator Period boundaries when you re-start
the system (it’s part of the TableAlteror routine during startup), but
- you have to re-start the system
- you will lose any non-default boundary settings used for any program
indicator.
This has also been reported as a high-priority bug on JIRA (DHIS2-4260).
Regards
Calle
Calle Hedberg
46D Alma Road, 7700 Rosebank, SOUTH AFRICA
Tel/fax (home): +27-21-685-6472
Cell: +27-82-853-5352
Iridium SatPhone: +8816-315-19119
Email: calle.hedberg@gmail.com
Skype: calle_hedberg
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp
–
Calle Hedberg
46D Alma Road, 7700 Rosebank, SOUTH AFRICA
Tel/fax (home): +27-21-685-6472
Cell: +27-82-853-5352
Iridium SatPhone: +8816-315-19119
Email: calle.hedberg@gmail.com
Skype: calle_hedberg
Calle Hedberg
46D Alma Road, 7700 Rosebank, SOUTH AFRICA
Tel/fax (home): +27-21-685-6472
Cell: +27-82-853-5352
Iridium SatPhone: +8816-315-19119
Email: calle.hedberg@gmail.com
Skype: calle_hedberg
