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.
-- 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 <knu...@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 <mor...@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...) >> >> >> -- >> 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.hedb...@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 >>> >>> On 12 July 2018 at 08:57, Bob Jolliffe <bobjolli...@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.hedb...@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 >>>> <https://maps.google.com/?q=46D+Alma+Road,+7700+Rosebank,+SOUTH+AFRICA&entry=gmail&source=g> >>>> > >>>> > Tel/fax (home): +27-21-685-6472 >>>> > >>>> > Cell: +27-82-853-5352 >>>> > >>>> > Iridium SatPhone: +8816-315-19119 >>>> > >>>> > Email: calle.hedb...@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 >>> <https://maps.google.com/?q=46D+Alma+Road,+7700+Rosebank,+SOUTH+AFRICA&entry=gmail&source=g> >>> >>> Tel/fax (home): +27-21-685-6472 >>> >>> Cell: +27-82-853-5352 >>> >>> Iridium SatPhone: +8816-315-19119 >>> >>> Email: calle.hedb...@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 >>> >>> >> _______________________________________________ >> 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 >> >
_______________________________________________ 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
