1eade4ae58
This introduces a pin/update operation which allows to Pin a new item to cluster indicating that said pin is an update to an already-existing pin. When this is the case, all the configuration for the existing pin is copied to the new one (including allocations). The IPFS connector will then trigger pin/update directly in IPFS, allowing an efficient pinning based on DAG-differences. Since the allocations where the same for both pins, the pin/update can proceed. PinUpdate does not unpin the previous pin (it is not possible to do this atomically in cluster like it happens in IPFS). The user can manually do it after the pin/update is done. Internally, after a lot of deliberations on what the optimal way for this is, I opted for adding a `PinUpdate` option to the `PinOptions` type (carries the CID to update from). In order to carry this option from the REST API to the IPFS Connector, it is serialized in the Protobuf (and stored in the datastore). There is no other way to do this in a simple fashion since the Pin object is piece of information that is sent around. Additionally, making it a PinOption plays well with the Pin/PinPath APIs which need little changes. Effectively, you are pinning a new thing. You are just indicating that it should be configured from an existing one. Fixes #732
28 lines
579 B
Protocol Buffer
28 lines
579 B
Protocol Buffer
syntax = "proto3";
|
|
package api.pb;
|
|
|
|
message Pin {
|
|
bytes Cid = 1;
|
|
enum PinType {
|
|
BadType = 0; // 1 << iota
|
|
DataType = 1; // 2 << iota
|
|
MetaType = 2;
|
|
ClusterDAGType = 3;
|
|
ShardType = 4;
|
|
}
|
|
PinType Type = 2;
|
|
repeated bytes Allocations = 3;
|
|
sint32 MaxDepth = 4;
|
|
bytes Reference = 5;
|
|
PinOptions Options = 6;
|
|
}
|
|
|
|
message PinOptions {
|
|
sint32 ReplicationFactorMin = 1;
|
|
sint32 ReplicationFactorMax = 2;
|
|
string Name = 3;
|
|
uint64 ShardSize = 4;
|
|
reserved 5; // reserved for UserAllocations
|
|
map<string, string> Metadata = 6;
|
|
bytes PinUpdate = 7;
|
|
} |