Question about custom path & backup

[piperun]

Hi!
I'm wondering just how you're suppose to set a custom path (in my case I just want to store the database in production in getApplicationSupportDirectory() instead of getApplicationDocumentsDirectory().

Also when it comes to importing/exporting the database I didn't quite get the documentation's example.

[simolus3]

I'm wondering just how you're suppose to set a custom path (in my case I just want to store the database in production in getApplicationSupportDirectory() instead of getApplicationDocumentsDirectory().

Are you using drift_flutter? In that case, use the databasePath argument to DriftNativeOptions.

Also when it comes to importing/exporting the database I didn't quite get the documentation's example.

The example mainly shows how to use existing databases that you might have as an asset for initial data. Are you looking for a way to implement save/restore functionality based on database files?

[piperun]

Are you using drift_flutter? In that case, use the databasePath argument to DriftNativeOptions.

Yes, sorry for asking this but, where exactly can you access DriftNativeOptions? I tried looking into driftDatabase:

  static QueryExecutor _openConnection() {
    // `driftDatabase` from `package:drift_flutter` stores the database in
    // `getApplicationDocumentsDirectory()`.
    return driftDatabase();
  }

But could only see: DriftWebOptions.

The example mainly shows how to use existing databases that you might have as an asset for initial data. Are you looking for a way to implement save/restore functionality based on database files?

Correct, essentially I just want to have the ability to import/export said database (and by extension be able to backup the database)..

[piperun]

No problem!

Forgive my ignorance here, but I realized just now that theoretically I could do:
AppDatabase(name: "import_db_file", path: customPath) and close when needed to, that would count as an import right?

But I assume there has to be some reason (and ideally I would like if there was a small section in the documentation about importing/exporting the database) to choose:

Future<void> importDatabase(String importPath) async {
  if (importPath.isNotEmpty) {
    final dbFolder = await getApplicationDocumentsDirectory();
    final targetPath = p.join(dbFolder.path, "test_backup.sqlite");
    if (await File(targetPath).exists()) {
      await File(targetPath).delete();
    }

    await Isolate.run(() async {
      final database = sqlite3.open(importPath);
      database.execute("VACUUM INTO ?", [targetPath]);
      database.dispose();
    });
  } else {}
}
// other file:
AppDatabase(name: "test_backup");

Over something like:
(Wrote this mostly to ensure it's simple enough to get the main idea across that we can swap out the database, in the real application we would most likely have a Provider class making this possible & have proper "default path string" in a setting)

Future<void> openDefaultDatabase() async {
  final database = AppDatabase(name: "default_db");
  await database.doTasks();
  await database.close();
}

Future<void> openAnyDatabase(String name, Future<String> Function ()? customPath) async {
    final database = AppDatabase(name: name, DriftNativeOptions(
          databasePath: customPath,
        ));
  await database.doTasks();
  await database.close();
}

Or have I completely misunderstood this?

[simolus3]

AppDatabase(name: "import_db_file", path: customPath) and close when needed to, that would count as an import right?

Yes, but then you need to remember the imported path if you want the import to survive app restarts. Depending on the OS, you might also not have write permissions for the selected file (e.g. a read-only copy shared with your app).
That's the only reason for copy contents over, if that's not relevant for you, just opening the imported file (perhaps as read-only) directly is indeed easier and no other downsides come to mind.

[piperun]

Thank you very much for this information, my last question would then be, if we then follow the documentation's recommendation, is this why drift defaults to getApplicationDocumentsDirectory() instead of getApplicationSupportDirectory()? To essentially ensure we always will have write access?

[simolus3]

getApplicationSupportDirectory() would have arguably been a better choice. There is no strong reason for this outside of backwards compatibility now, you can safely use a custom path in the support directory.