QUERYING BIGCHAINDB

A hub administrator can utilize the full intensity of MongoDB’s question motor to look and inquiry all put away information, including all exchanges, resources, and metadata. The hub administrator can choose for themselves the amount of that inquiry control they open to outer clients. I don’t get that’s meaning?

Assume that Sergio Tillenham plans in vogue custom vehicles. He needed to make a reliable record of Sergio Tillenham vehicle proprietors, with the goal that potential purchasers could look into the past proprietors of every vehicle. (The possession history, or provenance, influences the estimation of a vehicle.) Moreover, in the event that somebody guarantees a vehicle was planned by Sergio Tillenham; however, it’s not in the database, at that point it must be a phony. Likewise, if the vehicle is in the database yet the underlying record wasn’t made and marked (cryptographically) by Sergio, at that point it’s additionally phony.

Sergio chose to utilize BigchainDB. He made an arrangement with the top of the line vendors who sell his autos: in the event that a seller needs to sell his vehicles, at that point they should run a hub in his vehicle proprietorship database (fueled by BigchainDB). This gives every seller the additional advantage of having the full intensity of MongoDB to inquiry the database [7].

A BigchainDB exchange is a serialized article: a JSON string. One sends a BigchainDB exchange to a BigchainDB arranges in the body of a HTTP POST demand, and if it’s substantial, it gets put away by the system.

The CREATE Transaction

A CREATE transaction begins the history of each car in Sergio’s BigchainDB network. The “asset” part of the CREATE transaction has some information about the car itself. A name, color, and creation date and time are randomly generated. Here’s an example:

{"data": {"type": "car",

"name": "Restless Bonus",

"color": "cream",

"datetime_created": 1075128200,

"designer": "Sergio Tillenham"}}

The"metadata" part of a CREATE transaction is set to:

{"notes": "The CREATE transaction for one particular car (an asset) ."}

You may have noticed the strange format of the “datetime_created” in the above example, i.e., 1075128200. That’s a POSIX time stamp, also knowm as a Unix time stamp. We stored times that way to make certain queries easier. (MongoDB also has Date objects, but BigchainDB doesn’t support those yet.) As it happens, 1075128200 is the POSIX time stamp of 14:43:20 on January 26, 2004 (UTC). (We told the script to generate a random time between 30 years ago and 3 years ago.)

Each CREATE transaction is signed by Sergio Tillenham’s private key and he is the first owrner, i.e., the condition on the transaction’s sole output says that it can only be transferred if Sergio Tillenham signs the TRANSFER transaction.

The First TRANSFER Transaction

The first TRANSFER transaction (for each car) is special because it always transfers the car from Sergio to its first owner. We assumed that the first transfer happens within two years of the time the car was created.

The “asset” part of the first TRANSFER transaction looks like:

{"id":

"816c4dd7ael0b59al0f7016aacd685a5a41b402b3394a4264583d25 851af1629" }

where the long hex string is the asset id of the car (and also the transaction ID of the CREATE transaction where it was created).

The “metadata” part of the first TRANSFER Transaction looks like:

{"notes": "The first transfer, from Sergio to the first owner.", "new_owner": "Matthew Wheeler",

"transfer_time": 1101566600}

The name of the new owner is randomly generated. The transfer time is between zero and two years after the creation time, also randomly generated. In this case, l Ю1566600 is 14:43:20 on November 27, 2004 (UTC).

All Other TRANSFERS

The transfer to the next owner, if it happens at all, is assumed to happen within 365 days (about ten years). The time interval is randomly generated. More transfers are generated until the generated transfer time is in the future and therefore, hasn’t happened yet.

The “asset” part of the first TRANSFER transaction looks the same as in the first TRANSFER transaction. The “metadata” part looks like Figure 3.7.

{"notes": null,

"new_owner": "Laurie Jones",

"transfer_time": 1228920200}

 
Source
< Prev   CONTENTS   Source   Next >