The `name` property of the schema object is the name of the class (i.e. `Role`
for the role object) rather than the schema name (i.e. `__Role`). This happened
to work if only the predefined schema objects were used and no user-defined
classes had the non-underscore-prefixed names, but broke otherwise.
* Restore support for opening query-based sync Realms with a dynamic schema
* Adjust how the schema is extended for query-based Realms
* Register constructors for permissions types even no schema is supplied
* Remove some cruft from tests
* Fix a use-after-free in dynamic schema mode
* Fix a test
* Adding permission schema when opening the Realm
* Adding permission schema implicitly for query based Realms
* Remove old code
* Remove outdated test
being open with a different schema version
In order to correctly open read-only synchronized Realms, `Realm.open`
would open the Realm without specifying a schema or schema version, wait
for any remote changes to be downloaded (if appropriate), and then
re-open the Realm with the specified schema and schema version. This
would lead to an exception about the Realm being open with a different
schema version if the Realm had previously been opened with a different
schema version, due to the way `RealmCoordinator` caches information
about the schema of open Realms.
We address this by making two changes:
1. `Realm.open` for non-synchronized Realms no longer goes through
`_waitForDownload`. This means the dance described above where the Realm
is opened twice is not used for local Realms.
2. `_waitForDownload` no longer keeps the `Realm` alive until after its
callback has returned. It instead keeps the `SyncSession` alive. This is
sufficient to avoid the connection being torn down and having to
reconnect when `_waitForDownload`'s callback later opens the Realm with
the correct schema and schema version, while also allowing for
`RealmCoordinator`'s cached information to be cleared when the
schemaless Realm is closed prior to the Realm being reopened.
In addition, tests have been added that reproduced the problem in both a
local and sync context.
There's no reason for `_waitForDownload` to be responsible for
constructing a new Realm instance when we can instead use the
constructor for that. This eliminates the potential for different
handling of the Realm configuration between `_waitForDownload` and `new
Realm`, which was responsible for various issues (#1391, #1392, #1393).
In turn, this requires that `_waitForDownload` become an instance method.
In addition, we update `Realm.openAsync` and `getSpecialPurposeRealm` to
delegate to `Realm.open` rather than reimplementing equivalent logic
themselves.
Finally, the private mechanism for registering a download progress
handler as part of the sync configuration (`_onDownloadProgress`) is
removed in favor of the public API (`progress()` on the promise returned
by `Realm.open`).
Thomas Goyne
Nikola Irinchev
Thomas Goyne
Kenneth Geisshirt
Christian Melchior
Nabil Hachicha
astigsen
Gerhard de Clercq
Mark Rowe
blagoev
Maximilian Alexander
Yavor Georgiev