phpmyadmin / phpmyadmin/sql-parser
Re-formating LIMIT destroys DELETE and UPDATE queries
オープン
まだ誰も着手していません。
bug
- 主要言語
- PHP
- スター
- 485
- フォーク
- 119
- PR マージ指標
- 30日以内にマージされた PR はありません
説明
When building queries, the LIMIT is re-formatted. For example SELECT * FROM tbl LIMIT 1 is changed to SELECT * FROM tbl LIMIT 0, 1. This works just fine for SELECT queries, but not for DELETE or UPDATE queries.
Example:
$query1 = "DELETE FROM a LIMIT 1";
$parser = new PhpMyAdmin\SqlParser\Parser($query1);
$statement = $parser->statements[0];
$table2 = new \PhpMyAdmin\SqlParser\Components\Expression("", "b", "", "");
$statement->from[0] = $table2;
echo $statement->build();
results in
DELETE FROM `b` LIMIT 0, 1
The changed query fails, while the original query is perfect SQL.
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
まず、報告に示されている Parser コンストラクターと statement->build() の例で問題を再現し、次に DELETE 文と UPDATE 文で LIMIT がどのように構築されるかを追跡します。Issue にはファイルもテストも指定されていません。完了条件は、再構築された DELETE クエリと UPDATE クエリが有効な LIMIT 構文を維持し、SELECT の動作が引き続き正しいことです。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- mysql, php, sql
- 領域
- database
- issue の種類
- バグ
- 難易度
- 3/5
- 見積もり時間
- 1〜2日
- 活発さ
- 停滞
- 明瞭さ
- 明確に書かれている
- 初心者へのやさしさ
- 48/100