Skip to content
This repository has been archived by the owner on Jul 1, 2022. It is now read-only.

Add ability to get ordered tx history of an entity #37

Merged
merged 2 commits into from
Feb 14, 2017

Conversation

sohkai
Copy link
Member

@sohkai sohkai commented Feb 9, 2017

Implements entity histories through the api/v1/transactions?asset_id API.

As the API may not necessarily return a correct chain of transactions, we post process the list given back to order them properly.

else:
raise
return reraises_if_not
return decorator


def order_transactions(transactions):
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cc @libscott in case you were curious about the result of our conversation earlier about reconstructing a list of transaction's orders.

@codecov-io
Copy link

codecov-io commented Feb 9, 2017

Codecov Report

Merging #37 into master will increase coverage by 0.56%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master      #37      +/-   ##
==========================================
+ Coverage   98.21%   98.78%   +0.56%     
==========================================
  Files           3        3              
  Lines          56       82      +26     
==========================================
+ Hits           55       81      +26     
  Misses          1        1
Impacted Files Coverage Δ
coalaip_bigchaindb/plugin.py 97.87% <100%> (+0.37%)
coalaip_bigchaindb/utils.py 100% <100%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b6c43be...f14b34b. Read the comment docs.

@sohkai sohkai mentioned this pull request Feb 10, 2017
Copy link
Contributor

@TimDaub TimDaub left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I reviewed this in #18 already lol

Checking that there exists only one transaction that is not a input
dependency for any other transaction makes the missing transaction and
multiple non-fulfill checks redundant.

Missing transaction: If there were a missing transaction, the
transaction immediately preceding the missing transaction would be found
to be an extra non-depended-upon transaction.

Non-fulfill: Each transaction that isn't dependent on any other
transaction creates a non-depended-upon transaction at their end. If
there are multiple of these transactions, given that each transaction
can only contain one input dependency, there would be multiple
non-depended-upon transactions found in the list.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants