معرفی شرکت ها
djblockchain-0.1.1
تبلیغات ما
مشتریان به طور فزاینده ای آنلاین هستند. تبلیغات می تواند به آنها کمک کند تا کسب و کار شما را پیدا کنند.
مشاهده بیشتر
تبلیغات ما
مشتریان به طور فزاینده ای آنلاین هستند. تبلیغات می تواند به آنها کمک کند تا کسب و کار شما را پیدا کنند.
مشاهده بیشتر
تبلیغات ما
مشتریان به طور فزاینده ای آنلاین هستند. تبلیغات می تواند به آنها کمک کند تا کسب و کار شما را پیدا کنند.
مشاهده بیشتر
تبلیغات ما
مشتریان به طور فزاینده ای آنلاین هستند. تبلیغات می تواند به آنها کمک کند تا کسب و کار شما را پیدا کنند.
مشاهده بیشتر
تبلیغات ما
مشتریان به طور فزاینده ای آنلاین هستند. تبلیغات می تواند به آنها کمک کند تا کسب و کار شما را پیدا کنند.
مشاهده بیشترتوضیحات
djblockchain is a Django app which provides tables to store data about
| ویژگی | مقدار |
|---|---|
| سیستم عامل | - |
| نام فایل | djblockchain-0.1.1 |
| نام | djblockchain |
| نسخه کتابخانه | 0.1.1 |
| نگهدارنده | [] |
| ایمیل نگهدارنده | [] |
| نویسنده | James Pic |
| ایمیل نویسنده | jamespic@gmail.com |
| آدرس صفحه اصلی | https://yourlabs.io/oss/cli2 |
| آدرس اینترنتی | https://pypi.org/project/djblockchain/ |
| مجوز | MIT |
djblockchain is a Django app which provides tables to store data about
blockchain transactions with a blockchain abstraction layer and a deployment
spooler workflow.
The Transaction table holds transaction data such as the contract name,
address, function to call if any, and arguments in a JSONField, so you don't
have to query the blockchain to display transaction informations to users.
When you create a Transaction in djblockchain, it's "state" will be "held" by
default. Nothing happens when the state is "held", but change it to "deploy"
and the spooler will find that there is a new Transaction to deploy on the
blockchain.
The spooler will then set the Transaction.state to "deploying" to indicate that
it is trying to deploy, and then call Transaction.deploy() which is in charge
of deploying the contract or calling a function. It will retry as long as you
want, to prevent failing just because of a network error or something. In case
of success, it will set the Transaction.state to "watch" and then spool itself
again to ensure any further modification will be done in its own database
transaction.
Note that djblockchain supports custom Transaction subclasses which translates
into new tables with a foreign key to the Transaction table, thanks to Django
Model Inheritance feature. This allows Equisafe to have a dedicated subclass
per contract type of method call type, and override the deploy method to add
custom logic when needed.
The spooler will find the Transaction with state="watch" and call
Transaction.watch() which will wait until enough blocks append on the
blockchain to reduce the risk of loosing the transaction. It waits 5 minutes by
default, in the case of an error it will return and the spooler will try to
watch this Transaction again later because it will still be in the "watch"
state, trying to move forward the state of the other Transactions that you may
have in the database. In the case of success, it will set the state to
"postdeploy", and return to ensure that nothing else causes a database
transaction abort.
The spooler will then find the Transaction with state="postdeploy", and if your
custom Transaction class has a postdeploy() method then it will set the state
to "postdeploying" and call that. This is were you can chain calls on the
blockchain, for example with NyX, the IssuingEntity Transaction class
represents an issuing entity contract which is used to create the KYCIssuer
contract. So, we have IssuingEntity.postdeploy() which creates a KYCIssuer
Transaction subclass that the spooler will find and try to deploy and so on.
Note that the deploy and watch implementation are Provider based, we currently
have 3 providers:
- Tezos
- Ethereum
- Fake
As such, it makes it easy to migrate from Ethereum to Tezos, and the Fake
provider is, well, a fake blockchain provider that fakes contract addresses in
the deploy() and watch() functions. This makes it easy to test/develop your
user interface without even involving the blockchain. Note that we also
maintain a Tezos sandbox which behaves like the Ethereum sandbox to make tests
easier.
As per requirements, there should only be one spooled job per transaction
sender at the time. The spooler will do several sender accounts in parallel,
but not treat several transactions of a same sender in parallel.
While nothing can prevent that in theory with uWSGI spooler, this is ensured by
the Account.spool method which retrieves the Caller responsible for this
Account sender_spool, and only spools it if it's not currently running. So, the
sender_queue job should only be spooled by the Account.spool() method.
This is tested by the test_concurrency, which creates two accounts and creates
3 transactions in parallel, the two first with the first user account and the
last one with the second user account.
It will then wait until all transactions are finished, and compare the state
history entries as such:
- the second transaction should not start prior to the first one finishing,
because they are of the same sender account, avoiding nonce race conditions
- the third transaction should start in parallel with the first transaction,
because they are of different sender accounts, so that one failing sender
account does not block other sender accounts
Note that state_set will also add a new entry with the timestamp and the state
name in the new Transaction.history JSON list field. This is also logged with
the INFO level.
States recap:
- held: this transaction is only stored in the database
- deploy: this transaction should be deployed when possible
- deploying: this transaction is currently being deployed
- watch: this transaction has been deployed, it needs to be watched
- watching: this transaction is currently being watched
- postdeploy: this transaction has been watched and it needs to execute postdeploy
- postdeploying: this transaction's postdeploy method is currently being executed
- done: this transaction is finished
This is tested in the test_state, that runs a uWSGI server in a process fork
with a mini-project dedicated to testing djblockchain.djblockchain offers an easy fault-tolerant Django app to maintain a database of
contracts with blockchain synchronization.
زبان مورد نیاز
| مقدار | نام |
|---|---|
| >=3.8 | Python |
نحوه نصب
نصب پکیج whl djblockchain-0.1.1:
pip install djblockchain-0.1.1.whl
نصب پکیج tar.gz djblockchain-0.1.1:
pip install djblockchain-0.1.1.tar.gz