This also makes sure that
room account data does not
get unnecessarily serialized
and deserialized before
storing it in the database.
For this it changes the
code flow at multiple
places.
This changes the database
api a little bit so that it does
not unnecessarily serialize
and deserialize all
account data objects. Should
improve the performance of
the SDK.
- BREAKING: create `DatabaseApi.storeWellKnown` method
- BREAKING: create `DatabaseApi.getWellKnown` method
- add new getter `Client.wellKnown` containing cached `DiscoveryInformation`
- override `Client.homeserver` to invalidate `Client.wellKnown` in case the domain changed
- override `Client.getWellknown` to cache the resolved `DiscoveryInformation`
- add tests for well-known cache
Fixes: #1865
Signed-off-by: The one with the braid <info@braid.business>
At least in our CI this throws a null assertion error and since we
explicitly expect this to sometimes be null in our code, we should store
it as such.
You can either set them to private on the client or overwrite the
behaviour for that on each readMarker call. This also handles incoming
thread receipts and tries its best to figure out what is the latest
receipt. This however breaks the old m.receipt account data event.
The workaround was from the
time when we have used
sqflite or when Hive had
bugs. But now HiveCollections
already supports transactions
in Dart zones and concurrent
write operations shouldn't
be a problem anymore.
- implement session export
- implement session import
Please note, this is not device dehydration but a fully offline session
dump eligible for e.g. TOR users.
Signed-off-by: Lanna Michalke <l.michalke@famedly.com>
Due to server bugs or whatever it sometimes
happens that old state events appear
in the setState method in the room class.
Previously we checked if we already know
this event ID, but for this we needed to
check the timeline which is very fluid.
Also this is a database operation in a
non-async method which works in Hive but
not in Sembast.
Using originServerTs is not 100% safe as
well but should be more stable because
the chance that servers have veeery wrong
time (which is necessary here) is much
lower than the risk that the timeline
is not long enough to know the
old event.
Previously we had a check which uses the old
sortOrder value.
This check has been removed with the refactoring which leads to
bug #209. This fixes it by checking if the
event is already known in the database.
I am not 100% happy with this solution as this database api is impossible
to be implemented with a sqlite db. Once we start to refactor the whole sync update logic
we maybe could find a better way, but only the fox god knows.
RoomUpdate came from a time where we had no data model for
SyncUpdates but now we have and therefore this class is just
code duplication. This removes the class
and uses the SyncRoomUpdate class from
the package matrix_api_lite instead.
It needed a lot of refactoring at some places
where I also have removed some unnecessary null or type checks.
Krille
Mohammad Reza Moradi
The one with the braid
td
krille-chan
Krille
Nicolas Werner
Lanna Michalke
Henri Carnot
Jayesh Nirve
Lukas Lihotzki