dynamic.copy returned a type
error so I reverted the previous
change of the copyMap
method to an extension. Also
I found out that we have used
two copyMap methods in the
SDK which did exactly the same.
I deleted the old one and
changed the tests.
Unfortunately we need to copy
all maps. I took the opportunity
and abstracted the copy map
method to utils. I kept the
copyMap method as a
reference in HiveCollections
database to not require a
huge refactoring there as we
are going to ditch it anyway.
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.
This makes sure that the deleteFromDisk() method is
called AFTER the clear while
the execution order was
random before which could
lead to the problem that
Hive tries to clear a box after
it got deleted.
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>
States were used before being fetched from the database.
Thus, room membership states weren't set, and so,
user display names weren't be fetched from the database.
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.
fix: add room invite update to roomStateBox, so invites don't show empty room when app is restarted
Closes#228
See merge request famedly/company/frontend/famedlysdk!865
Events with a status of 1 should be sorted in the normal timeline.
They should not be stucked at the bottom. This fixes a bug
where a limited timeline flag
can stuck a SENT event at the bottom of
the chat forever.
When requesting history the `start` parameter could become larger than the loaded events
from the database were, resulting in an error when attempting to request history.
If a box is corrupted the clear function fails on it. Then
we should delete the box from the disk.
Currently we use the Hive.deletefromDisk() method which does not
work because it deletes only open boxes, but the box is obviously not open in
this case.
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.
This is an edge case which might occour
on unstable data connections. The user sends an event and receives the sync
before the response to the sending
http request. This leads to duplicated
events while the response actually
should be ignored at this point.
The current implementation of sortOrder can be made way more easier now
by just keeping the sortOrder of the list
and the timelineFragments in the hiveStore. This needed a huge
change but mostly removes a lot of code which can be done
way more easy now. This also needed some rewriting of the setState logic and changes to
the prevEvent calculation. This solution should also be more stable.
More information:
https://www.reddit.com/r/fluffychat/comments/pfnlhq/the_sort_order_of_matrix_timelines/
That way some concurrency bugs might be fixed, such as if two sync
requests are processed at the same time. That can e.g. happen if you
request history while a sync request is already being processed.
We have used some data models which were only used in moor in the tests.
I needed to rewrite them in the original data as well.
Also now the "fake database" on native is the same like on web now with hive.
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.
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.
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.
Krille
Krille
Nicolas Werner
td
henri2h
Lanna Michalke
TheOneWithTheBraid
Henri Carnot
Jayesh Nirve
Jindra
Jindřich Pikora
Sorunome
Lukas Lihotzki
Marcus