* Consider ledgers incompatible based on last valid ledger
* Test against even ledgers not acquired yet
* Don't validate an incompatible ledger
* Don't switch to an incompatible ledger
* Protect against an unreasonably small quorum
This implements the tracking of when an amendment achieved a majority
in the ledger, ensuring that there's always network-wide agreement
on which amendments have achieved a majority and how long they've
held it.
* New fields
* Change transactor changes
* AmendmentTable API and implementation changes
* Update amendment enabled status on validated ledgers
* Reinstate support for ledger sequence in fee transactions
The View hierarchy of classes is reorganized to include new
classes with member functions moved and renamed, to solve
defects in the original design:
OpenView accumulates raw state and tx changes and
can be applied to the base. ApplyView accumulates changes
for a single transaction, including metadata, and can be
applied to an OpenView. The Sandbox allows changes with
the option to apply or throw them out. The PaymentSandbox
provides a sandbox with account credit deferral.
Call sites are changed to use the class appropriate for
the task.
The OpenLedger class encapsulates the functionality of
maintaining the open ledger. It uses an OpenView with the
last closed ledger as its base. Routines are provided to
modify the open ledger to add new transactions, and to
accept a new last closed ledger. Business logic for
performing transaction retries is rewritten to fit this
framework and used in the implementation of accept.
When the RIPPLE_OPEN_LEDGER macro is set to 1 (BeastConfig.h),
the global Application OpenLedger singleton maintains
its open ledger in parallel by applying new transactions
and accepting new last closed ledgers. In the current
implementation this does not affect transaction processing
but logs any differences in the results as compared to
the original code.
Logging shows an occasional mismatch in what the OpenLedger
builds versus the original code, usually an OfferCreate
which gets a terINSUF_RESERVE instead of tesSUCCESS.
This tidies up the View interface and makes transaction
application a free function, with the removal of the
TransactionEngine class. A new class ApplyContext provides
all the state information needed to apply a Transactor. The
Transactor is refactored to perform all the processing
activities previously part of TransactionEngine.
The calculation of metadata from a MetaView is improved.
A new apply function performs all the steps for calculating
and inserting metadata into the tx map.
Transaction processing code path is passed a Config instead
of retrieving the global, and uses the Journal supplied in
the call to apply() consistently.
To support transaction processing and RPC operations, a
new POD type ViewInfo is added which consolidates static
information about open and closed ledgers, such as the ledger
sequence number or the closing times. Ledger and MetaView are
refactored to use this info.
The ViewInfo now contains the "open ledger" setting. The
tapOPEN_LEDGER ViewFlag is removed. The view property of
being an open ledger is obtained from the base or by using
the MetaView constructor which presents a closed ledger as
an open one.
View, MetaView:
* Fix missing includes
* Add apply free function
* Use Journal in TransactionEngine
* Use BasicView in TransactionEngine
* inline NetworkOPs::batchApply
* Add shallow_copy, open_ledger MetaView ctor tags
* Add ViewInfo with open flag, seq, close times
* Make parent_ a reference
* Tidy up ctor arguments and base_ name
* Remove tapOPEN_LEDGER
* add assert to MetaView::apply
* ViewInfo comment
* Throw, pass Journal in txInsert
* Add BasicView::txCount
TransactionEngine:
* Add apply
* Make TransactionEngine private
* Refactor MetaView::apply and apply()
* Rename to TxMeta
* Refactor treatment of metadata in MetaView, TransactionEngine
* Rename to ApplyContext
* Use ApplyContext& in Transactor
* Pass Config in ApplyContext
* Declare Transactor classes in headers
* Use view flags in Transactor
This shores up the View interface support for contextual
transaction processing by putting params in the View, and
provides support for replacing the open ledger with the
open MetaView.
Transaction metadata is now part of the View interface.
Stacked MetaViews correctly apply their transaction
metadata to the parent.
* Add lastCloseTime to View
* Add insertTx to View, implement in MetaView
* Add View::txExists for transaction checking
* Add Fees to View, cache fees in Ledger and MetaView
* Use ViewFlags in View
* Use tapENABLE_TESTING flag for features
* Use cached Fees in View
* Rename to ViewFlags
* Move FreezeHandling to View.h, remove ViewAPIBasics.h
* Remove BasicView::parent hack
* Remove calls to getLedger in Transactors
Member functions and free functions on Ledger and LedgerEntrySet are
rewritten in terms of new abstract interfaces `BasicView` and `View`,
representing the set of non-decomposable primitives necessary to read
and write state map items in a ledger, and to overlay a discardable
view onto a Ledger that can calculate metadata during transaction
processing. const-correctness is enforced through the parameter and
return types.
The MetaView now supports multi-level stacking: A MetaView can be
stacked on top of either a Ledger or another MetaView, up to any
number of levels.
The getSLEi member function is removed. The CachedView wrapper
replaces it, wrapping a View such that any function called with a
CachedView will go through the SLECache.
* Add BasicView, View, CachedView
* Rename LedgerEntrySet to MetaView
* Factor out free functions
* Consolidate free functions in ViewAPI
* Remove unused class members and free functions