project-tsurugi / tsurugidb Goto Github PK

ディレクトリ名に誤りがあるようです。 2 -> 1

https://github.com/project-tsurugi/tsurugidb/releases/tag/1.0.0-BETA1

- curl -OL https://github.com/project-tsurugi/tsurugidb/releases/download/1.0.0-BETA2/tsurugidb-1.0.0-BETA1.tar.gz
+ curl -OL https://github.com/project-tsurugi/tsurugidb/releases/download/1.0.0-BETA1/tsurugidb-1.0.0-BETA1.tar.gz

LTXはserializableとのことですが、条件付きreadの結果に依存してINSERTをするとwrite skew (という用語でよいのかは自信ありません)が発生するようです。
SELECT SUM(value) + 1 FROM fooの結果をfooにINSERTする、というのを2つのトランザクションから並行して実施した場合、両方とも成功します。

実行環境:

• Docker版tsurugi:latest (Id: sha256:438aad9c6c49c51c97253dd6e363abc8366ede009b5899ca38975cb36a051365, Created: 2023-10-05T02:34:58.823587414Z)
• tgsql

準備

CREATE TABLE test (
  id int PRIMARY KEY,
  value int NOT NULL
);

INSERT INTO test (id, value) VALUES (1, 1);

COMMIT;

トランザクション1 (途中まで)

BEGIN LONG TRANSACTION WRITE PRESERVE test;

-- 本来は
-- INSERT INTO test (id, value) VALUES (2, SELECT SUM(value) + 1 FROM test);
-- と書きたいが、まだサポートされていないので、クライアント側でSELECT結果をINSERTに渡しているものとする。

SELECT SUM(value) + 1 FROM test;
INSERT INTO test (id, value) VALUES (2, 2); -- 前のSELECTの結果。
-- まだコミットはしない

トランザクション2(途中まで)

BEGIN LONG TRANSACTION WRITE PRESERVE test;

SELECT SUM(value) + 1 FROM test;
INSERT INTO test (id, value) VALUES (3, 2); -- 前のSELECTの結果。
-- まだコミットはしない

トランザクション1

COMMIT;

トランザクション2

COMMIT;

この場合、2つのトランザクションはserializableでないのでどちらかはCOMMITに失敗するはずですが、両方ともコミットに成功します。
なお、トランザクション2を先にCOMMITしようとした場合、トランザクション2がブロックされ、トランザクション1がコミットしたタイミングでトランザクション2がCC_LTX_PHANTOM_AVOIDANCEでエラーとなるため問題ありません。
まだ使い方などよく理解しておらず、書き方に問題があればご指摘いただけると助かります。
(あと、Issueは日本語で大丈夫でしょうか)

コンポーネントの命名に関して提案があり、issueを作成させていただきました。
issueの作成は初めてなので、何か不備があればご指摘いただけると幸いです。

現在のコンポーネントの命名は、機能に関連しない固有名詞が非常に多く、プロジェクトに精通していない人間には非常にわかりにくいです。
これは、このプロジェクトの発展に大きく影響すると思います。

命名が分かりにくいことによる具体的な問題として、環境構築やエラーが起こった際の対応などで、どの名前がどの機能に対応するか、都度都度確認しなければならず、その対処にかかる時間が余計に増えてしまうことが挙げられます。
また、機能に関する議論をしようと思ったときにも、これは妨げになります。
現状の命名では、このプロジェクトが実用を意識していないように見え、実際に実用に耐えられるものかどうかに関して、少なからず心証を損ねます。

私自身、国産の技術を心から応援したいと思っていますが、現在の命名方法では全面的な支持が難しいと感じています。
プロジェクトのさらなる普及や成長を考えると、命名方法の見直しは欠かせないと考えます。

もちろん、すぐにすべてを変更するのは難しいかと思いますが、tsurugi-<機能名>のような命名に段階的に移行することを検討していただけると幸いです。