Hm. So no error message? Might it have been some kind of timeout? I could add some try/catch around the archive creation. maybe there could occur errors if an archive is some sort of "broken".

btw. maybe we should try to find a way to have long running updates in the browser.
Most scripts should be splitable into smaller parts that could be run one after the other doing some kind of page reload in the browser to avoid timeouts.
Guess that should easily be possible for loops doing queries like in that update script. We just would need to pass the current step/item with the url on page reload to start from there then.

No error message 👎 I didn't investigate much further. I'm not so sure we should run the upgrade anyway, as it could be just too huge. To provide them an option I'd just create the console command rather than try execute it in the browser... I don't think people will care so much if they lose the OS/Browsers historical data (before enabling DeviceDetection).

we could rename the existing archives. which should not take too long. That would mean only archives with browser version would be available for older data. browser family reports would then be missing.

@sgiehl this sounds good to me! +1

Ok. I'll have a look at that within the next few days

@mattab Please review my changes. The archives will now only be renamed/replaced if required. Archive rebuilding won't be done anymore. Instead the API will build the reports on the fly out of the archives with versions if requested.

There's still a little bug with periods != day. I'll try to fix that tomorrow

Everything should be fixed here then. Hope the update doesn't fail this time on demo. If not guess we can close the ticket.

Hi Stefan! The upgrade worked on the demo and demo2 :)