Documentation
¶
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
func Fail ¶ added in v0.33.30
Fail returns an anonymous function, whose future execution returns the error e. This is useful for front-loading sanity checks. On the happy path (dominant), this function will generally not be used. However, if one of the front-loaded sanity checks fails, we include `transaction.Fail(e)` in place of the business logic handling the happy path.
func Update ¶
Update creates a badger transaction, passing it to a chain of functions. Only if transaction succeeds, we run `callbacks` that were appended during the transaction execution. The callbacks are useful update caches in order to reduce cache misses.
Types ¶
type Tx ¶
Tx wraps a badger transaction and includes and additional slice for callbacks. The callbacks are executed after the badger transaction completed _successfully_. DESIGN PATTERN
- DBTxn should never be nil
- at initialization, `callbacks` is empty
- While business logic code operates on `DBTxn`, it can append additional callbacks via the `OnSucceed` method. This generally happens during the transaction execution.
CAUTION:
- Tx is stateful (calls to `OnSucceed` change its internal state). Therefore, Tx needs to be passed as pointer variable.
- Do not instantiate Tx outside of this package. Instead, use `Update` or `View` functions.
- Whether a transaction is considered to have succeeded depends only on the return value of the outermost function. For example, consider a chain of 3 functions: f3( f2( f1(x))) Lets assume f1 fails with an `storage.ErrAlreadyExists` sentinel, which f2 expects and therefore discards. f3 could then succeed, i.e. return nil. Consequently, the entire list of callbacks is executed, including f1's callback if it added one. Callback implementations therefore need to account for this edge case.
- not concurrency safe
func (*Tx) OnSucceed ¶
func (b *Tx) OnSucceed(callback func())
OnSucceed adds a callback to execute after the batch has been successfully flushed. Useful for implementing the cache where we will only cache after the batch of database operations has been successfully applied. CAUTION: Whether a transaction is considered to have succeeded depends only on the return value of the outermost function. For example, consider a chain of 3 functions: f3( f2( f1(x))) Lets assume f1 fails with an `storage.ErrAlreadyExists` sentinel, which f2 expects and therefore discards. f3 could then succeed, i.e. return nil. Consequently, the entire list of callbacks is executed, including f1's callback if it added one. Callback implementations therefore need to account for this edge case.
Source Files