calendaring_sync.objects.resolution module

How your application resolves a conflict.

class calendaring_sync.objects.resolution.KeepServer

Bases: object

Keep the server’s copy, and drop your local edit.

Where the server has the object, the record takes the server’s copy, which for an edit the server refused is the synced copy. Where it doesn’t, because the server removed the object or refused your create, the record is removed, or deleted if the server never had it.

class calendaring_sync.objects.resolution.KeepLocal

Bases: object

Push your local edit as it is, over the server’s current copy.

Where the server removed the object, a change goes out as a create. An edit the server didn’t allow goes out again, for when the server would now take it, such as once you may write to the object. An edit the server refused because another object holds its logical key can’t go out unchanged, so this refuses it; it’s pending again by itself once that object stops holding the key.

class calendaring_sync.objects.resolution.Merge(content, fields)

Bases: object

Push content you merged from the conflict’s versions, over the server’s current copy.

A record in conflict holds three versions of its object: the synced copy both sides last agreed on, in content; your local edit, in edit; and the server’s copy, in conflict. Your application merges them into new content, and reads its fields with the adapter’s edit_fields(), so they match what a sync reads from the server’s copy. Where the server removed the object, the merge goes out as a create.

content

The merged content.

Type:

bytes

fields

Its fingerprint, containers and logical key.

Type:

EditFields

Raises:

• TypeError – If a field has the wrong type.

• LoneSurrogateError – If a string holds a lone surrogate.

Examples

Your application keeps the room your edit set and the time the server’s copy moved to, in one copy. An adapter would read its fields; these are made up:

>>> from calendaring_sync import EditFields, Merge
>>> content = b"Team meeting, room 3, moved"
>>> merged = Merge(content, EditFields("fp-merged"))
>>> merged.fields.fingerprint
'fp-merged'

class calendaring_sync.objects.resolution.Delete

Bases: object

Delete the object, whatever the server’s copy holds.

Where the server has the object, the delete goes out over its current copy, and for a change or delete the server refused, that’s the object the edit was for. Where the server doesn’t have it, the record is removed, or deleted if the server never had it.

class calendaring_sync.objects.resolution.UpdateHolder

Bases: object

Push a refused edit as a change to the object that holds its logical key.

Only for a create or a change refused because another object holds its logical key. A refused create then leaves nothing, and the object a refused change was for stays as it was synced.

class calendaring_sync.objects.resolution.ResolvedConflicts(resolved=(), left_open=(), changed=())

Bases: object

What resolve_conflicts() did with each conflict.

Each field holds local keys, in the order the conflicts were passed to your resolver.

resolved

The conflicts resolved as your resolver answered.

Type:

tuple[int, ...]

left_open

The conflicts your resolver answered None for.

Type:

tuple[int, ...]

changed

The conflicts that changed while your resolver ran, so its answer wasn’t applied. The next call passes them again.

Type:

tuple[int, ...]

calendaring_sync.objects.resolution.Resolution: TypeAlias = calendaring_sync.objects.resolution.KeepServer | calendaring_sync.objects.resolution.KeepLocal | calendaring_sync.objects.resolution.Merge | calendaring_sync.objects.resolution.Delete | calendaring_sync.objects.resolution.UpdateHolder

Any one of the five.