dhis2-devs team mailing list archive

[Calle Hedberg <calle.hedberg@xxxxxxxxx>]

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

On 12 July 2018 at 08:57, Bob Jolliffe <bobjolliffe@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxx
> >
> > Skype: calle_hedberg
> >
> > *******************************************
> >
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~dhis2-devs
> > Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> > 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@xxxxxxxxx

Skype: calle_hedberg

*******************************************