Should the serialized params schema name the kinds of reference?

Abierto
  • ¿Algo no está bien?
#88 3 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
python
Área
backend-api-design

Línea de trabajo

Read SerializedWorkflowSpec.params_schema, the pydantic models that generate the form, and the backend field_types.fits logic. The form-generator spike is a prerequisite; this issue leaves two schema designs and output matching behavior undecided. Done means those questions have a decision and the schema and service behavior reflect it.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

In SerializedWorkflowSpec.params_schema, each place that takes a reference to an output lists the kinds of reference by name:

"beam_centre": {"anyOf": [{"$ref": "#/$defs/BeamCentre", "not": {"required": ["@ref"]}},
                          {"anyOf": [{"$ref": "#/$defs/OutputRef"}, {"$ref": "#/$defs/AccumulatorRef"}],
                           "dataType": "BeamCentre"}]}

So every spec's schema contains framework concepts (records, accumulators). A UI generated from the schema offers an accumulator picker even if the app has no accumulators. Adding a kind of reference would change the schema of every spec.

Alternative. The spec says only "data of type X, by reference": one generic reference form with dataType. The framework decides which kinds of reference can supply that data. Counterpoint: the schema also validates request JSON, which holds concrete @ref objects. A generic {"@ref": <kind>, ...} form could still do that job, but it would validate less strictly.

Related: matching outputs to places by name. dataType is the bare class name (field_types.type_name). The backend uses field_types.fits, which accepts a subclass of the class at the place. Matching on the dataType string cannot see subclass fits, and two packages that each define a Sample get the same name. A UI without the workflow package could ask the backend which records have outputs that fit a place, instead of comparing names. The service has the packages installed, so it can run fits itself.

To be decided after the form-generator spike. The spike generates the form from the pydantic models, so it does not run into either question.

Lenguaje dominante
Python
Estrellas
0
Forks
1
Merge medio
9 h 23 min
PR fusionados (30 d)
65

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de scipp/essapps

Todos los issues de scipp/essapps

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.