Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

storage-postgres: DeleteTable's response omits VectorIndexes that DescribeTable reports

オープン 初心者向け
#656 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 4 日以内に返信

まだ誰も着手していません。

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
70/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
postgresql, rust
領域
databases

調査の方向性

crates/storage-postgres/src/delete_table.rsから始めて、build_table_description_from_rowを読み、同じテーブルに対してDescribeTableがVectorIndexesをどのように設定するか比較してください。DeleteTableの説明を更新してこれらのインデックスを含め、その後、関連するstorage-postgresのテストで応答が一致するか確認してください。DeleteTableとDescribeTableの両方がテーブルのベクトルインデックスを報告すれば完了です。

索引モデルが issue の本文から書いたものです。

説明

backend:postgresql bug

DeleteTable's response is built by build_table_description_from_row in crates/storage-postgres/src/delete_table.rs, which never sets VectorIndexes. A concurrent DescribeTable of the same table includes them ([{"IndexName":"vidx","IndexStatus":"ACTIVE", ...}]), so the two descriptions of one table differ in that member.

Observed on main cf321f05 on a vector table with two GSIs: GlobalSecondaryIndexes is present in both; VectorIndexes is null in the DeleteTable response and populated in DescribeTable.

VectorIndexes is an ExtendDB extension, so this is a self-consistency point rather than a DynamoDB difference. Expected: the DeleteTable description includes the table's vector indexes as DescribeTable does. Found while reviewing #395 (its DELETING-table branch reuses the same builder); out of scope there.

主要言語
Rust
スター
517
フォーク
60
平均マージ
4日 22時間
マージ済み PR(30日)
40

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

ExtendDB/extenddb のほかの issue

ExtendDB/extenddb の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。