Bigchaindb: Condition.cid & Fulfillment.fid: Either should be always neccesary or never neccesary.

Created on 17 Nov 2016  路  7Comments  路  Source: bigchaindb/bigchaindb

Currently our (still pending in #798) schema definition has cid and fid as optional fields, in their respective objects. These fields should either be mandatory or non-present.

They are necessary if we cannot depend on array order from our underlying database. Otherwise, they are not neccesary, and the cid and fid will be implicit given the array of conditions and fulfillments, respectively.

Personally I'm on the side of relying on databases to maintain sequence, as we are using arrays and not sets.

Given the result of this we should either remove [c|f]id or make them mandatory.

cc @sohkai tx milestone?

Most helpful comment

I should have clarified; the cid pointer inside the fulfillment (Fulfillment.cid) would stay, it's Condition.cid and Fulfillment.fid which we are looking at keeping or not keeping.

Correct. We'll have to keep the cid in fulfillments[x].input.cid. Everything else can (and should) be removed.

All 7 comments

I'm not sure how a fulfillment would point to the condition that it's fulfilling if it can't use a (transaction id, condition id) pair. Can you clarify that? Suppose, for the sake of example, that the conditions being fulfilled are in a variety of previous transactions (i.e. for the same asset but it's a divisible asset so spread out across many previous transactions' conditions).

I should have clarified; the cid pointer inside the fulfillment (Fulfillment.cid) would stay, it's Condition.cid and Fulfillment.fid which we are looking at keeping or not keeping.

Edit: to clarify, the condition that Fulfillment.cid points to would be evident by it's location in the Transaction.conditions array, not by it's self reported cid (redundant if you trust that the order is maintained in the array).

I should have clarified; the cid pointer inside the fulfillment (Fulfillment.cid) would stay, it's Condition.cid and Fulfillment.fid which we are looking at keeping or not keeping.

Correct. We'll have to keep the cid in fulfillments[x].input.cid. Everything else can (and should) be removed.

Now have a branch for this, it wasn't such a big change: https://github.com/bigchaindb/bigchaindb/commit/b22392c5cc354973fef8122b691275dc7c5ea2f7

Will make a PR next week hopefully.

I personally don't feel comfortable in hoping that the order of an array will be maintained between all the json serialization going on bigchaindb and the serialization to different binary formats when handling multiple databases

I personally don't feel comfortable in hoping that the order of an array will be maintained between all the json serialization going on bigchaindb and the serialization to different binary formats when handling multiple databases

If we can't trust our datastore to maintain array order we have other problems too, because the block ID depends on the order of transactions in a block, tx ID relies on order of public keys, etc.

If the datastore doesn't preserve array order we will have a hard time verifying anything in the database.

Yes that is true. sort_keys does not sort the elements on the array

Was this page helpful?
0 / 5 - 0 ratings