1package dag
 2
 3import (
 4	"github.com/MichaelMure/git-bug/entity"
 5	"github.com/MichaelMure/git-bug/identity"
 6)
 7
 8// Operation is a piece of data defining a change to reflect on the state of an Entity.
 9// What this Operation or Entity's state looks like is not of the resort of this package as it only deals with the
10// data structure and storage.
11type Operation interface {
12	// Id return the Operation identifier
13	//
14	// Some care need to be taken to define a correct Id derivation and enough entropy in the data used to avoid
15	// collisions. Notably:
16	// - the Id of the first Operation will be used as the Id of the Entity. Collision need to be avoided across entities
17	//   of the same type (example: no collision within the "bug" namespace).
18	// - collisions can also happen within the set of Operations of an Entity. Simple Operation might not have enough
19	//   entropy to yield unique Ids (example: two "close" operation within the same second, same author).
20	//   If this is a concern, it is recommended to include a piece of random data in the operation's data, to guarantee
21	//   a minimal amount of entropy and avoid collision.
22	//
23	//   Author's note: I tried to find a clever way around that inelegance (stuffing random useless data into the stored
24	//   structure is not exactly elegant) but I failed to find a proper way. Essentially, anything that would reuse some
25	//   other data (parent operation's Id, lamport clock) or the graph structure (depth) impose that the Id would only
26	//   make sense in the context of the graph and yield some deep coupling between Entity and Operation. This in turn
27	//   make the whole thing even less elegant.
28	//
29	// A common way to derive an Id will be to use the entity.DeriveId() function on the serialized operation data.
30	Id() entity.Id
31	// Validate check if the Operation data is valid
32	Validate() error
33	// Author returns the author of this operation
34	Author() identity.Interface
35}