Backups

> db:drop deletes both, the database and the corresponding backups

> db:info($db)/resourceproperties/inputdate is a UTC dateTime with a time zone offset > db:backups($db)/@date is a local dateTime without a time zone offset

> db_alter() has not changed. It alters the name of the database but the corresponding backups stay unchanged. I combine it with db:drop-backup()

> I copied the old data, restxq etc. into the new structure. > … > In both cases I lost my users. How can I upgrade without loosing them?

On Mon, Oct 21, 2019 at 1:47 PM Christoph Gaukel <christoph.gaukel at gmx.de> wrote: > > Hi Christian, > > thank you for your answer. I upgraded from 9.1.2 to 9.2.4 and indeed: > > the output of db:backups('test_balance_tmp') changed from: > <backup database="test_balance_tmp" date="2019-10-18T00:05:50" size="2230">test_balance_tmp-2019-10-18-00-05-50</backup> > to: > <backup database="test_balance_tmp" date="2019-10-17T22:05:50Z" size="2230">test_balance_tmp-2019-10-18-00-05-50</backup> > > The same with db:drop(), now it deletes the database but not the backups. > > db_alter() has not changed. It alters the name of the database but the corresponding backups stay unchanged. I combine it with db:drop-backup() > > > From doing the upgrade, I got a new question. I have done two trials: > > I copied the old data, restxq etc. into the new structure. > I copied BaseX.jar and basex/lib into the old structure > > In both cases I lost my users. How can I upgrade without loosing them? > > > Thanks, > > Christoph > > Am 18.10.19 um 10:25 schrieb Christian Grün: > > Hi Christoph, > > Welcome back to the list. > > db:drop deletes both, the database and the corresponding backups > > The function should only delete database and preserve backups. For > deleting backups, db:drop-backup can be used. Maybe there was a bug in > an older version of BaseX? > > db:info($db)/resourceproperties/inputdate is a UTC dateTime with a time zone offset > db:backups($db)/@date is a local dateTime without a time zone offset > > Same here: Both returned timezones should be a UTC dateTime with the Z > time offset. > > Maybe you need to switch to the latest version of BaseX? > Feel free to give us an update if the problems persist with BaseX 9.x. > > Hope this helps, > Christian >

On Wed, Oct 16, 2019 at 1:34 PM Christoph Gaukel <christoph.gaukel at gmx.de> wrote: > > Hi, > > the following handling of backups is surprising: > > db:alter changes the name of the database but does not alter the names of the corresponding backups > db:drop deletes both, the database and the corresponding backups > > I would prefer, if there was an option in db:drop to keep the backups, which would allow to restore a deleted database from their backups. Is it possible to add options to db:drop, which allow that? > > For me, the behavior of db:alter looks like a bug. > > > There is another minor handling, i would like to have changed: > > db:info($db)/resourceproperties/inputdate is a UTC dateTime with a time zone offset > db:backups($db)/@date is a local dateTime without a time zone offset > > If I compare these two, it works correctly if the local time zone offset is the same as for the creation of the backup E.g.: > > if ( > not(db:backups($db)) or > max(db:backups($db)/@date/(. cast as xs:dateTime)) < > db:info($db)/resourceproperties/inputdate/. cast as xs:dateTime > ) then db:create-backup($db) > else () > > Adding a time zone offset +hh:mm or -hh:mm to db:backups($db)/@date would solve this. > > > Thanks, > > Christoph > >