Inconsistency in examples

[MichalNemec]

Hello,
I have couple of questions regarding work with drift and powersync.

1. should we use drift schema or powersync schema?
2. when i do the example, i dont have any option to connect to get syncing, how does it work then?
3. Can we have the database in isolate?

---

if powersync schema is used, then views are created, so drift does not work.

Can someone shed light on this with examples, how it should be actually implemented?

For context: coming from drift + electric

how i have it now, which i really dont like.

final dbPath = await getDatabasePath();
final db = SqliteDatabase(path: dbPath);
_chatDb = ChatDatabase(db); //drift 
final powerSync = PowerSyncDatabase.withDatabase(schema: schema, database: db);
await _chatDb!.customSelect("SELECT 1").get();
powerSync.connect(connector: MyBackendConnector(powerSync));
_chatDao = ChatDao(_chatDb!); //dao for queries

[rkistner]

For a full example, see this:
https://github.com/powersync-ja/powersync.dart/pull/60/files

should we use drift schema or powersync schema?

You currently need to define both - powersync for managing the database, and drift for managing your DAOs. Just avoid running drift migrations - that will conflict with the powersync views.

We can look into auto-generating the powersync schema from the Drift schema in the future.

when i do the example, i dont have any option to connect to get syncing, how does it work then?

See the example above, it does including syncing. The examples in the drift_sqlite_async repo are for usage without PowerSync.

Can we have the database in isolate?

Yes, the underlying sqlite_async does work with Isolates. Some considerations:

1. Best is to pass db.isolateConnectionFactory to other Isolates. This preserves locks and update notifications across isolates.
2. You'll need to create a new drift database using that instance in each isolate.
3. If you can't pass the connection factory between isolates, you can open a new database instance. You lose update notification propagation between instances when doing this.
4. Never call db.connect in multiple isolates at the same time, that has the potential to corrupt the database.

See more discussion on usage with Isolates in our Discord here:
https://discord.com/channels/1138230179878154300/1219308397019660380/1219308397019660380

how i have it now, which i really dont like.

It can be simplified slightly, see the example linked above. But it should only be a once-off setup either way.

[rkistner]

Yes, sqlite_async (and by extension powersync) automatically opens a connection pool using background Isolates, in addition to one isolate for the sync connection. You can configure the maximum number of read isolates using maxReaders in the constructor.

[MichalNemec]

Got it thank you, lastly the only issue i get is that the database is opened multiple times, it occures only sometimes.

final dbPath = await getDatabasePath();
      print("Using chat database at path $dbPath");
      _powerSync = ps.PowerSyncDatabase(schema: schema, path: dbPath);
      _chatDb = ChatDatabase(_powerSync!);
      await _chatDb!.customSelect("SELECT 1").get();
      _chatDao = ChatDao(_chatDb!);
      _powerSync!.connect(connector: ChatBackendConnector(_powerSync!));

ChatDatabase is the drift stuff and it triggers there, which looks like this now:

class ChatDatabase extends _$ChatDatabase {
  ChatDatabase(ps.PowerSyncDatabase db) : super(SqliteAsyncDriftConnection(db));

  @override
  int get schemaVersion => 1;

  @override
  MigrationStrategy get migration {
    return MigrationStrategy(
      onCreate: (m) async {
        //
        print("Dummy onCreate");
      },
    );
  }
}

[rkistner]

Is it possible that it's just Flutter's hot restart triggering that during development, or do you see it in other cases as well?

[MichalNemec]

Yes, that very well could be, since its sometimes. With plain drift, that didnt happen tho

[rkistner]

I know drift has a very specific workaround for a similar issue: simolus3/drift#835

In that case it doesn't prevent the new instances from being opened, but just has a workaround to close the old instances.

In general, if it is just the hot reload issue, you can ignore it in most cases. There may be rare cases where you run into "database is locked" errors, where you have to kill and restart the app to recover. But that should not affect production builds.

If you suspect it's more than that, let us know and we can investigate further.