astrodbtoolkit / astrodbtoolkit/AstrodbKit
Consider ingest/updates via changes (delta)
- 主要言語
- 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