astrodbtoolkit / astrodbtoolkit/AstrodbKit

Consider ingest/updates via changes (delta)

オープン
#79 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る
主要言語
Python
スター
12
フォーク
5
PR マージ指標
30日以内にマージされた PR はありません

説明

Currently, updating the database is the same as creating a new one- all records are deleted and re-ingested. This works well to ensure that objects that are deleted are properly handled. However, once the database reaches a certain size this can be an expensive operation.

Instead, we may want to figure out how to handle a delta-style ingest, that is, only process those JSON documents that have been updated. This may be tricky and may require several iterations.
I do think for purposes of Production-level databases and testing one may want to build the entire database, so this is more thinking about the development aspect or user's local copies were they may not want/need a production-ready instance. Or for instances were the production-level database is so large we only want to apply deltas.

I can think of several aspects we may want to check out:

1. Perform no deletions, only insert JSON files that have been produced. This is already supported, but when saving the database by default this saves all JSON output. It's also not clear if we'd have foreign key violations, particularly if reference tables have been updated.
2. Use git diff to determine which JSON documents have changed. Do not delete or change anything else. This requires git installed and for the data to be version controlled, both likely true in development situations.
3. Figure out a way to export only records that have changed when saving the database. I do not know if there is a way to capture all changes to the DB since a connection was made. It might be architecture-dependent, but it starts getting into DB data migration tools of which several exist but our DB/Tool architecture wasn't built with them in mind.

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

調査の方向性

この issue では、ファイル、テスト、エントリポイントが指定されていません。まず、現在のデータベース作成、更新、JSON 保存のパスをマッピングし、次に提案されている no-deletion、git-diff、change-export のアプローチを比較します。完了条件は、削除と外部キーの動作を定義した、選択済みの delta-ingest 設計があることです。

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

評価

技術スタック
git, python, sqlalchemy
領域
database
issue の種類
機能追加
難易度
5/5
見積もり時間
1週間以上
活発さ
停滞
明瞭さ
説明が足りない
初心者へのやさしさ
25/100

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

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