Android sqlite backup/restore without overwriting -

question in short form: seems followups should perhaps emphasize , simplify core of question. core this: other backup options android dbs seems leave risk restore overwrite data in database. so, , there way backup/restore without risk?

.

question in long form: having looked through many of (rather numerous) questions backing up sqlite db on android have 1 question couldn't find answer to.

all other backup/restore discussions dealt saving db file sd (or, in how backup/restore sqlite database on android dropbox, cloud), , restoring when required. concern is, wouldn't restore overwrite current db?

i'm concerned when user has new install of app they've been using short time (generating new data) , want import data previous backup of app. other backup/restore approaches seems restoring old db file overwrite new data in current db file. want instead backup option that, on restore, add data backup current db make complete without overwriting else in it.

do other approaches this? or they, suspect, overwrite in such case?

if overwrite best backup option write out csv or xml file or , expected these backup discussions easy ways that. there processes build speed process , make easy or have manually? if so, recommendations on format write , why?

similarly, know if built in google backup using backupagenthelper have same overwrite issue?

and finally, if end going through data migration (similar how restore sqlite database backup after core data model has changed (lightweight migration)) @ point should (i'm still in db design stage) make such potential future change easier vis-à-vis backup process?

i think problem of restoring old data without changing (or conflicting with) ‘newer’ data not hard solve in scenario describe. seems want ‘add’ old data (records) new database assumption old data has no logical conflict newer data (that is, semantically ok create new records old data). believe taking care of primary key conflicts during restoration important issue consider.

let’s take 2 cases:

1: using auto generation of primary key values feature of database (e.g., using autoincrement column of sqlite table).

let’s assume ‘newer’ database records might have used primary key (rowid) values of 1 10 before restoration process started. if have ‘older’ database records of primary key values (1 10), have problem if want preserve old primary key values. avoid problem, don’t retain ‘old’ primary key value of an‘old’ record – after reading record ‘old’ database, save values of other attributes (columns) of ‘old’ record , let database generate new primary key value ‘restored’ record. essentially, ‘old’ record saved new primary key value. if concerned maintaining chronological order of records after ‘restoration’ process, suggest keep timestamp column value not changed in process.

2: using alternate mechanism (uuid, sequence generators, etc.) generating primary key values:

in case, read ‘old’ record , before saving in ‘newer’ database, replace ‘old’ primary key value primary key value generated alternate mechanism – would, design, guarantee uniqueness of primary key value of ‘restored’ record respect pre-existing ‘newer’ records.

to simplify programming effort ‘restoration’ process, if dealing multiple tables, may use orm jdxa. 1 of sample apps shipped sdk illustrates similar technique transferring ‘old’ data while upgrading database newer version. jdxa offers convenient sequence generator mechanism , efficiently create unique ids can assign objects before persisting them.