问题
老同事今天问我,A合约inline调用B合约的action(B合约的action中的逻辑会修改B合约的某个Table),A合约中执行完inline后,立刻查B合约中的Table数据,数据未更新,怎么处理。
解决方案
A合约inline调用B合约的action后,B再内联调用A合约的另一个新加的action(在这个action中再查B合约的Table数据)
先暂时记录下,等下再跟下链代码,详细分析下为什么合约是同步执行的,然而inline action 出现了“异步的效果”
老同事今天问我,A合约inline调用B合约的action(B合约的action中的逻辑会修改B合约的某个Table),A合约中执行完inline后,立刻查B合约中的Table数据,数据未更新,怎么处理。
A合约inline调用B合约的action后,B再内联调用A合约的另一个新加的action(在这个action中再查B合约的Table数据)
先暂时记录下,等下再跟下链代码,详细分析下为什么合约是同步执行的,然而inline action 出现了“异步的效果”
下载地址:https://dev.mysql.com/downloads/mysql/8.0.html
mysql-8.0.19-winx64.zip
C:\Program Files\mysql-8.0.19-winx64
C:\Program Files\mysql-8.0.19-winx64\data
C:\Program Files\mysql-8.0.19-winx64\logs
[mysqld]
#安装目录
basedir = C:\Program Files\mysql-8.0.19-winx64
#数据文件目录
datadir = C:\Program Files\mysql-8.0.19-winx64\data
port = 3306
server_id = 1
general_log = ON
general_log_file = C:\Program Files\mysql-8.0.19-winx64\logs\mysql.log
log_error = C:\Program Files\mysql-8.0.19-winx64\logs\error.log
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
character-set-server = utf8mb4
performance_schema_max_table_instances = 600
table_definition_cache = 400
table_open_cache = 256
#sql_mode=ONLY_FULL_GROUP_BY,NO_AUTO_VALUE_ON_ZERO,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION,PIPES_AS_CONCAT,ANSI_QUOTES
[mysql]
default-character-set = utf8mb4
[client]
default-character-set = utf8mb4
mysqld --initialize --console #不用特别指定default file默认会使用my.ini
控制台输入如下表示成功
C:\Program Files\mysql-8.0.19-winx64>mysqld --initialize --console
2020-04-21T10:11:25.148253Z 0 [Warning] [MY-010915] [Server] 'NO_ZERO_DATE', 'NO_ZERO_IN_DATE' and 'ERROR_FOR_DIVISION_BY_ZERO' sql modes should be used with strict mode. They will be merged with strict mode in a future release.
2020-04-21T10:11:25.148318Z 0 [System] [MY-013169] [Server] C:\Program Files\mysql-8.0.19-winx64\bin\mysqld.exe (mysqld 8.0.19) initializing of server in progress as process 8684
2020-04-21T10:11:47.571686Z 5 [Note] [MY-010454] [Server] A temporary password is generated for root@localhost: Fv?_a7%jn_R(
Warning
暂时没做理会,没发现使用异常
记下上面日志最后面的root的初始化密码Fv?_a7%jn_R(
,下面要用到
mysqld --install [服务名] #不写服务名默认为mysql
C:\Program Files\mysql-8.0.19-winx64>net start mysql
MySQL 服务正在启动 ..
MySQL 服务已经启动成功。
C:\Program Files\mysql-8.0.19-winx64>mysql -u root -p
Enter password: ************
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 10
Server version: 8.0.19
Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '要改的新密码';
git ls-files | xargs wc -l
BCS Token 购买 FF 资源
FF Bancor 算法过程中,并不是将 BCS 和 FF 直接用价格曲线进行兑换,而是引入了中间 token——FFCORE,对应于 Bancor 中的 Smart Token。
BCS 到 FF 的兑换过程就涉及了两个公式,所以上文中用一个公式来举例就很不严谨,只是为了定性的说明价格特性。
从代码中可看到BCS与FFCORE的兑换公式为:
其中,E为BCS到FFCORE所能兑换的数量,R是FFCORE的初始发行总量,C1为当前BCS余量,T1为用于购买的FF数量,F为常量参数
将上述公式的进行反向整理设计,即可得到FFCORE与交易额的兑换公式为:
其中,T2是准备购入的FF数量;C2为可分配的FF余量。将中间变量E代入即可得出用于购买的BCS数量(T1)与可兑换到的FF数量(T2)之间的关系。
为方便直观的理解,可以对公式进行简化,得到:
可以看到随着可买FF余量(C2)的降低或者BCS数量(C1)的增多,FF的价格会加速增长(即同样付出T1的BCS下,可换取到的FF数量T2变少了)
当get table索引是name 时,无法精准查询
因为cleos 传入的参数默认是字符串,需要对应的转换参数
--key-type name
例如
cleos -u https://api.eosnewyork.io:443 get table eosio eosio voters --key-type name -L 111111111122 -l 1