diff --git a/CHANGELOG.md b/CHANGELOG.md index 2ec4e04185..4927b9b974 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -2,17 +2,31 @@ ### Enhancements * Allow `ShouldCompactOnLaunch` to be set on `SyncConfiguration`, not only `RealmConfiguration`. (Issue [#3617](https://github.com/realm/realm-dotnet/issues/3617)) +* Reduce the size of the local transaction log produced by creating objects, improving the performance of insertion-heavy transactions (Core 14.10.0). +* Performance has been improved for range queries on integers and timestamps. Requires that you use the "BETWEEN" operation in `Realm.All().Filter(...)`. (Core 14.10.1) ### Fixed * A `ForCurrentlyOutstandingWork` progress notifier would not immediately call its callback after registration. Instead you would have to wait for some data to be received to get your first update - if you were already caught up when you registered the notifier you could end up waiting a long time for the server to deliver a download that would call/expire your notifier. (Core 14.8.0) * After compacting, a file upgrade would be triggered. This could cause loss of data if `ShouldDeleteIfMigrationNeeded` is set to `true`. (Issue [#3583](https://github.com/realm/realm-dotnet/issues/3583), Core 14.9.0) * Passing in a deleted object as a substitution argument to `.Filter()` would throw a confusing error with a message starting with `invalid RQL for table`. It now throws a more descriptive error instead. (Issue [#3619](https://github.com/realm/realm-dotnet/issues/3619)) +* Fix some client resets (such as migrating to flexible sync) potentially failing with AutoClientResetFailed if a new client reset condition (such as rolling back a flexible sync migration) occurred before the first one completed. (Core 14.10.0) +* Encrypted files on Windows had a maximum size of 2GB even on x64 due to internal usage of `off_t`, which is a 32-bit type on 64-bit Windows. (Core 14.10.0) +* The encryption code no longer behaves differently depending on the system page size, which should entirely eliminate a recurring source of bugs related to copying encrypted Realm files between platforms with different page sizes. One known outstanding bug was ([RNET-1141](https://github.com/realm/realm-dotnet/issues/3592)), where opening files on a system with a larger page size than the writing system would attempt to read sections of the file which had never been written to. (Core 14.10.0) +* There were several complicated scenarios which could result in stale reads from encrypted files in multiprocess scenarios. These were very difficult to hit and would typically lead to a crash, either due to an assertion failure or DecryptionFailure being thrown. (Core 14.10.0) +* Encrypted files have some benign data races where we can memcpy a block of memory while another thread is writing to a limited range of it. It is logically impossible to ever read from that range when this happens, but Thread Sanitizer quite reasonably complains about this. We now perform a slower operations when running with TSan which avoids this benign race. (Core 14.10.0) +* Tokenizing strings for full-text search could pass values outside the range [-1, 255] to `isspace()`, which is undefined behavior. (Core 14.10.0) +* Opening an Flexible Sync Realm asynchronously may not wait to download all data. (Core 14.10.1) +* Clearing a List of `RealmValue` in an upgraded file would lead to an assertion failing. (Core 14.10.1) +* You could get unexpected merge results when assigning to a nested collection. (Core 14.10.2) +* Fixed removing backlinks from the wrong objects if the link came from a nested list, nested dictionary, top-level dictionary, or list of `RealmValue`, and the source table had more than 256 objects. This could manifest as `array_backlink.cpp:112: Assertion failed: int64_t(value >> 1) == key.value` when removing an object. (Core 14.10.2-14-gf66e24d03) +* Fixed the collapse/rejoin of clusters which contained nested collections with links. This could manifest as `array.cpp:319: Array::move() Assertion failed: begin <= end [2, 1]` when removing an object. (Core 14.10.2-14-gf66e24d03) +* `Session.WaitForUpload()` was inconsistent in how it handled commits which did not produce any changesets to upload. Previously it would sometimes complete immediately if all commits waiting to be uploaded were empty, and at other times it would wait for a server roundtrip. It will now always complete immediately. (Core 14.10.2-14-gf66e24d03) ### Compatibility * Realm Studio: 15.0.0 or later. ### Internal -* Using Core 14.9.0. +* Using Core v14.10.2-14-gf66e24d03. ## 12.2.0 (2024-05-22) diff --git a/Tests/Realm.Tests/Sync/SynchronizedInstanceTests.cs b/Tests/Realm.Tests/Sync/SynchronizedInstanceTests.cs index 00fededf10..adadf62221 100644 --- a/Tests/Realm.Tests/Sync/SynchronizedInstanceTests.cs +++ b/Tests/Realm.Tests/Sync/SynchronizedInstanceTests.cs @@ -802,7 +802,7 @@ public void SyncLogger_WhenLevelChanges_LogsAtNewLevel() logs[level] = new(); } - var regex = new Regex("Connection\\[\\d+]: Session\\[\\d+]"); + var regex = new Regex("Connection\\[\\d+] Session\\[\\d+]"); var logger = Logger.Function((level, msg) => { if (regex.IsMatch(msg)) diff --git a/wrappers/realm-core b/wrappers/realm-core index f3d7ae5f9f..f66e24d035 160000 --- a/wrappers/realm-core +++ b/wrappers/realm-core @@ -1 +1 @@ -Subproject commit f3d7ae5f9f31d90b327a64536bb7801cc69fd85b +Subproject commit f66e24d035c987e35183cb8f0bcb864a8df8697c