Persisted outputs cannot be read after a spec version bump

Đang mở
  • Có gì không ổn?
#177 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
python
Lĩnh vực
backend

Hướng nghiên cứu

Start by reading the workspace output lookup and Store.read behavior described in the issue, then inspect the four options and their tradeoffs. The issue identifies no source files or tests; first locate the workspace and folder store implementations. Done means choosing and implementing a way to read persisted outputs across spec versions or workspaces, with tests that cover the selected behavior.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Since #174, Store.read(record, output, tp) takes the type that the spec declares for the output, and the workspace passes it from the binding of the record's spec:

spec_id = self._views.records.spec(ref.record)       # SpecId(name, version)
binding = self._bindings.get(spec_id)                # None -> NotReadable
tp = binding.spec.outputs.model_fields[ref.output].annotation
value = self._store.read(ref.record, ref.output, tp)

The reason: the folder store writes scipp HDF5, which holds no Python types, so a group (a pydantic model) can only be rebuilt from the declared type.

Consequence: a workspace reads the persisted outputs only of the specs it binds, by name and version.

bindings = [IOFQ v1]   -> persists record r1
upgrade: bindings = [IOFQ v2]
client.output(r1)      -> NotReadable: the workspace does not run loki-iofq v1

So after a version bump, the outputs persisted under the old version cannot be read, although the files are intact, and a request cannot reference them. The same holds for a second workspace that shares the store but runs other specs, which contradicts "workspaces share values only through the store" unless both bind the spec.

Options:

  1. Keep old versions bound. The deployment lists the bindings of every version whose outputs it still wants to read. No code change; the cost moves to whoever maintains the list.
  2. Bind specs for reading without a workflow. A workspace takes specs it only reads (WorkflowSpec without a binding). Reading then needs the spec's package, not its workflow's dependencies.
  3. Store the type with the value, e.g. the qualified class name as an attribute. Reading then needs neither binding nor spec, but imports a class by a name read from a file, and a renamed or moved class breaks old files.
  4. Read without the type, as plain DataGroup/dict, when the spec is not bound. The value is then not what the workflow returned, so check_fit and typed consumers do not apply.

I lean to 2: it keeps the rule that the spec says what an output is, and separates "can describe" from "can run".

Ngôn ngữ chính
Python
Star
0
Fork
1
Merge trung bình
8 giờ 48 phút
Pull request đã merge (30 ngày)
70

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của scipp/essapps

Tất cả issue của scipp/essapps

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.