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.hedb...@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 <mor...@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..) >> >> -- >> 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 <st...@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 <mor...@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. >>>> >>>> >>>> -- >>>> 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 >>>> >>>> >>> >>> >>> -- >>> Stian Sandvold >>> Software developer, DHIS2 >>> University of Oslo >>> http://www.dhis2.org >>> >> >> >> _______________________________________________ >> 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
