-
Notifications
You must be signed in to change notification settings - Fork 157
/
DiscardUnsyncedChangesHandler.cs
62 lines (58 loc) · 3.46 KB
/
DiscardUnsyncedChangesHandler.cs
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
////////////////////////////////////////////////////////////////////////////
//
// Copyright 2022 Realm Inc.
//
// Licensed under the Apache License, Version 2.0 (the "License")
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
//
////////////////////////////////////////////////////////////////////////////
namespace Realms.Sync.ErrorHandling
{
/// <summary>
/// A client reset strategy where all the not yet synchronized data is automatically discarded and a fresh copy of the synchronized Realm is obtained.
/// </summary>
/// <remarks>
/// The freshly downloaded copy of the synchronized Realm triggers all change notifications as a write transaction is internally simulated.
/// This strategy supplies three callbacks: <see cref="OnBeforeReset"/>, <see cref="OnAfterReset"/>, and <see cref="ManualResetFallback"/>.
/// The first two are invoked just before and after the client reset has happened,
/// while the last one will be invoked in case an error occurs during the automated process and the system needs to fallback to a manual mode.
/// The overall recommendation for using this strategy is that using the three available callbacks should only be considered when:
/// 1. the user needs to be notified (in <see cref="OnBeforeReset"/>) of an incoming potential data loss of unsynced data
/// 2. the user needs to be notified (in <see cref="OnAfterReset"/>) that the reset process has completed
/// 3. advanced use cases for data-sensitive applications where the developer wants to recover in the most appropriate way the unsynced data
/// 4. backup the whole realm before the client reset happens (in <see cref="OnBeforeReset"/>). Such backup could, for example, be used to restore the unsynced data (see 3.)
/// </remarks>
/// <seealso href="https://www.mongodb.com/docs/atlas/device-sdks/sdk/dotnet/sync/client-reset/">Client Resets - .NET SDK</seealso>
public sealed class DiscardUnsyncedChangesHandler : ClientResetHandlerBase
{
/// <summary>
/// Gets or sets the callback that indicates a Client Reset is about to happen.
/// </summary>
/// <value>Callback invoked right before a Client Reset.</value>
public BeforeResetCallback? OnBeforeReset { get; set; }
/// <summary>
/// Gets or sets the callback that indicates a Client Reset just happened.
/// </summary>
/// <value>Callback invoked right after a Client Reset.</value>
public AfterResetCallback? OnAfterReset { get; set; }
internal override ClientResyncMode ClientResetMode => ClientResyncMode.Discard;
/// <summary>
/// Gets or sets the callback triggered when an error has occurred that makes the operation unable to complete, for example in the case of a destructive schema change.
/// </summary>
/// <value>Callback invoked if automatic Client Reset handling fails.</value>
public ClientResetCallback? ManualResetFallback
{
get => ManualClientReset;
set => ManualClientReset = value;
}
}
}