toychainではじめるsqlite メモ書き

DBは三つで構成されている。

.schemaでテーブル構成が分かる。wallet, chain, txかな。

sqlite> .schema wallet
CREATE TABLE wallet (id INTEGER, xpriv, xpub, priv, pub, address, PRIMARY KEY (id));

sqlite> .schema chain
CREATE TABLE chain (id INTEGER, tx TEXT, parent JSON, edge JSON, spent INTEGER, PRIMARY KEY (id));

sqlite> .schema tx
CREATE TABLE tx (id TEXT, tx TEXT, genesis INTEGER, sent INTEGER, PRIMARY KEY (id));

はじめtxやろ！って見てみたが、見てもよく分からず、txとブロキャス前のtxだなぁ。これだけみてどうするんだろって思ってchainみた。

id: 62
tx: toyなtx
parent: [30]
edge: {
	"address":"発行したアドレス",
	"txId":"toyなtx",
	"outputIndex":1,
	"script":"76a9149ee03f3135f0b7b9ecabab953c3087a165b7764d88ac",
	"satoshis":1192
}
spent: 0

サンプルに1行抜いてきた。spentってのはutxo的なものだろうか。まぁ勝手に処理してくれるところはあとでしればいい。toychainの欠点はGETにあり、条件検索とかで引っ張ってきにくい。なので、もはやdb直で検索した方がいいと思っている。その際、chain.edgeがそれだなと分かる。因みにこのレコードは、公式のサンプルスクリプトを叩くと生成されるレコードです。内容はただの連番記述してtoyにブロードキャストしているだけです。つまり、公式にもほぼ同じものが記載されています(笑)。

と、眺めていたんですが、これはどうもあれらしい。ブロードキャスト前のbsv.Transactionでできるtxが、txTBLにあって、chainTBLもOP_RETURN的なものは格納していない。...なるほどどうりでpowpingでtoychainを使ってない訳です。あくまでtoychainはブロードキャスト前まで処理して、任意のタイミングでpushしてねってとこまでのものらしい。なので、OP_RETURNにいれるべきデータは別で自分で持っておいた方がいいっぽい。うーん、セカンドレイヤーはこの時は意識してなかったってことになるな...推理してもしょうがないけど。

どうりでGETが弱い訳だ。アップする前に参照して使うとかそんな想定してないと...。と、いうことでsqlite toychainはあくまでBCに上げるためのDB達でaddして、アップしないならaddのデータは自前で保管しておきなさいと。これだと、DBにぶっこんどいて、お好きにmbでアップしなさいとかわらなくね？どうする？

ちなみにtxTBL

id: toyのtx|
tx: ブロキャス前のhex(tx)|
genesis: 0|
sent: 0

genesisってのが上げたか、上げてないかみたいな。結局実行して試した人しか伝わらない書き方になったな。

DBを作る

# sqlite3 project.db

テーブルを作る

> create table user(id integer primary key autoincrement, type text, type_id integer, name text, mail text, avater text);

テーブルを確認する

> .table
> .schema

sqliteを抜ける

> .exit