If the currentVersion of the database is null then the database has never been used yet.
Therefore we store the current version and do not call the migrate method.
With the switch to hive a regression of sending the to_device key was
introduced: When popping elements .deleteAt(), so deleting at the index,
was used, instead of .delete(), so deleting of the key. As the new events
pushed onto the queue used hives auto increment key, a .delete() is
appropriate here.
You may have missed the last valid loginState from the stream if you
listen too late to it. This makes it possible to
get always the current loginState.
If you call BasicEvent.fromJson the given content is copied first
which recursively makes sure
that the Map is from type
Map<String,dynamic>.
Using just the constructor doesnt have this which can lead that nested Maps in
the content is InternallinkedHashMap and
therefore lead to type errors.
In Moor this was implemented but forgotten in Hive.
Events with status 0 (not sent yet) should be marked as failed on restart.
In fact they should be marked as failed if older than 1 minute. To not have a big startup job which iterates through all events in the database
we just do a time check when opening a room where we iterate through all events anyway.
The new implementation is now in the constructor of the Event and therefore
independent from the database implementation.
* check casts (for list and map) at cast time by recreating the list/map
instead of throwing on access.
* type warnings work now slightly differently:
* when we expect nullable fields to be actually null within normal
operation you can explicitly set the tryGet type param to an
optional type and mute the warning. Otherwise it'll warn that something
is null which we expect to something else.
Fixes that a sync could be done / processed while the client was still being initialized (loaded from database). This has lead to multiple bugs, such as the verified status of keys getting lost, notifications that come in during app startup displaying oddly, etc.
Additionally, the init lock was released too early; it is now released when the init is actually done.
This new sync status stream gives the current status of the sync to make it possible
to display in the UI where the sync currently hangs and
what the progress is while updating 1000 rooms. So the app can display a
progress bar.
The unawaited method from the pedantic package was a historic solution
for the case that you dont want to await a future in an async function.
But now we can do this with just a comment which
is the recommended way to do this now.
This makes it possible to have pedantic as a dev_dependency which means just one dependency less.
Currently we only migrate the client and SSSSCache but this leads to the
problem that we are no longer self signed after the migration.
We need to migrate all device keys too.
This also abstracts the migration code in a method. init() is too large already...
The hive database now implements the whole API except for storing files which
should be better done by the flutter_cache_manager package inside of the
flutter app. All tests already run with Hive now but the Moor database is still
tested too. We needed to change some wait jobs in the tests because the Hive
database is not 100% in memory for the tests like Moor.
For now both database implementations are equal and the developer can pick
which one to use but we plan to get rid of Moor in the future.
This makes sure that the database is null after clearing so it will
be built again using the databaseBuilder.
Also this makes sure that the sync has
aborted BEFORE the clearing starts to
get rid of some warnings in the logs.
Before the migration of the databases starts there is always a
logout signal sent. This was wrong.
This also cleans up the logs a little bit
and removes the useless parameters for the second init() call
because those are going to come from the new database anyway.
This allows the user to give a legacyDatabaseBuilder to the client object
and in the init proccess the client checks by itself if there is old data in the legacy
database. If yes then it migrates them and
then deletes the old database. This uses the database_api and is agnostic to
the database implementation.
Krille Fear
Sorunome
Lukas Lihotzki
Marcus Hoffmann