syncthing/proto/dbproto/structs.proto
Jakob Borg 77970d5113
refactor: use modern Protobuf encoder (#9817)
At a high level, this is what I've done and why:

- I'm moving the protobuf generation for the `protocol`, `discovery` and
`db` packages to the modern alternatives, and using `buf` to generate
because it's nice and simple.
- After trying various approaches on how to integrate the new types with
the existing code, I opted for splitting off our own data model types
from the on-the-wire generated types. This means we can have a
`FileInfo` type with nicer ergonomics and lots of methods, while the
protobuf generated type stays clean and close to the wire protocol. It
does mean copying between the two when required, which certainly adds a
small amount of inefficiency. If we want to walk this back in the future
and use the raw generated type throughout, that's possible, this however
makes the refactor smaller (!) as it doesn't change everything about the
type for everyone at the same time.
- I have simply removed in cold blood a significant number of old
database migrations. These depended on previous generations of generated
messages of various kinds and were annoying to support in the new
fashion. The oldest supported database version now is the one from
Syncthing 1.9.0 from Sep 7, 2020.
- I changed config structs to be regular manually defined structs.

For the sake of discussion, some things I tried that turned out not to
work...

### Embedding / wrapping

Embedding the protobuf generated structs in our existing types as a data
container and keeping our methods and stuff:

```
package protocol

type FileInfo struct {
  *generated.FileInfo
}
```

This generates a lot of problems because the internal shape of the
generated struct is quite different (different names, different types,
more pointers), because initializing it doesn't work like you'd expect
(i.e., you end up with an embedded nil pointer and a panic), and because
the types of child types don't get wrapped. That is, even if we also
have a similar wrapper around a `Vector`, that's not the type you get
when accessing `someFileInfo.Version`, you get the `*generated.Vector`
that doesn't have methods, etc.

### Aliasing

```
package protocol

type FileInfo = generated.FileInfo
```

Doesn't help because you can't attach methods to it, plus all the above.

### Generating the types into the target package like we do now and
attaching methods

This fails because of the different shape of the generated type (as in
the embedding case above) plus the generated struct already has a bunch
of methods that we can't necessarily override properly (like `String()`
and a bunch of getters).

### Methods to functions

I considered just moving all the methods we attach to functions in a
specific package, so that for example

```
package protocol

func (f FileInfo) Equal(other FileInfo) bool
```

would become

```
package fileinfos

func Equal(a, b *generated.FileInfo) bool
```

and this would mostly work, but becomes quite verbose and cumbersome,
and somewhat limits discoverability (you can't see what methods are
available on the type in auto completions, etc). In the end I did this
in some cases, like in the database layer where a lot of things like
`func (fv *FileVersion) IsEmpty() bool` becomes `func fvIsEmpty(fv
*generated.FileVersion)` because they were anyway just internal methods.

Fixes #8247
2024-12-01 16:50:17 +01:00

104 lines
2.6 KiB
Protocol Buffer

syntax = "proto3";
package dbproto;
import "bep/bep.proto";
import "google/protobuf/timestamp.proto";
// Same as bep.FileInfo, but without blocks
message FileInfoTruncated {
string name = 1;
int64 size = 3;
int64 modified_s = 5;
uint64 modified_by = 12;
bep.Vector version = 9;
int64 sequence = 10;
reserved 16; // blocks
string symlink_target = 17;
bytes blocks_hash = 18;
bytes encrypted = 19;
bep.FileInfoType type = 2;
uint32 permissions = 4;
int32 modified_ns = 11;
int32 block_size = 13;
bep.PlatformData platform = 14;
// The local_flags fields stores flags that are relevant to the local
// host only. It is not part of the protocol, doesn't get sent or
// received (we make sure to zero it), nonetheless we need it on our
// struct and to be able to serialize it to/from the database.
uint32 local_flags = 1000;
// The version_hash is an implementation detail and not part of the wire
// format.
bytes version_hash = 1001;
// The time when the inode was last changed (i.e., permissions, xattrs
// etc changed). This is host-local, not sent over the wire.
int64 inode_change_ns = 1002;
// The size of the data appended to the encrypted file on disk. This is
// host-local, not sent over the wire.
int32 encryption_trailer_size = 1003;
bool deleted = 6;
bool invalid = 7;
bool no_permissions = 8;
}
message FileVersion {
bep.Vector version = 1;
bool deleted = 2;
repeated bytes devices = 3;
repeated bytes invalid_devices = 4;
}
message VersionList {
repeated FileVersion versions = 1;
}
// BlockList is the structure used to store block lists
message BlockList {
repeated bep.BlockInfo blocks = 1;
}
// IndirectionHashesOnly is used to only unmarshal the indirection hashes
// from a FileInfo
message IndirectionHashesOnly {
bytes blocks_hash = 18;
bytes version_hash = 1001;
}
// For each folder and device we keep one of these to track the current
// counts and sequence. We also keep one for the global state of the folder.
message Counts {
int32 files = 1;
int32 directories = 2;
int32 symlinks = 3;
int32 deleted = 4;
int64 bytes = 5;
int64 sequence = 6; // zero for the global state
bytes device_id = 17; // device ID for remote devices, or special values for local/global
uint32 local_flags = 18; // the local flag for this count bucket
}
message CountsSet {
repeated Counts counts = 1;
int64 created = 2; // unix nanos
}
message ObservedFolder {
google.protobuf.Timestamp time = 1;
string label = 2;
bool receive_encrypted = 3;
bool remote_encrypted = 4;
}
message ObservedDevice {
google.protobuf.Timestamp time = 1;
string name = 2;
string address = 3;
}