Repository navigation
feat(core): feeder model proposal - #1144
Conversation
9ff3cdb to
44600c5
Compare
Documentation build overview
14 files changed ·
|
44600c5 to
62e857a
Compare
amaltaro
changed the title
83fb453 to
9b0538b
Compare
| RESOURCES = "diracx.resources" | ||
| SERVICES = "diracx.services" | ||
| LOCK_OBJECT_TYPES = "diracx.lock_object_types" | ||
| FEEDERS = "diracx.transformations.feeders" |
There was a problem hiding this comment.
I'm not sure about transformations vs transformation.
There was a problem hiding this comment.
I can change it to transformation, but honestly, I don't even understand where it comes from. Is it supposed to match a python package somewhere?
Note that diracx-{core,db,logic,tasks,routers} have different patterns, sometimes the package is plural, others it is singular.
There was a problem hiding this comment.
It gets used in the pyproject.toml files like: https://github.com/DIRACGrid/diracx/pull/1152/changes#diff-c6028abbeae6cf51d340ddfa1fe61e27d0ac47e8f941ce5db1d4e3cb95f2476f
It's an arbitrary string that just needs to be:
- vaguely readable
- unique
We seem to be settling into a namespace like layout with . to separate levels, starting with diracx. I guess we could go for only having two levels like:
diracx.feeders
There was a problem hiding this comment.
I'd go for diracx.transformation.feeders.
I don't like diracx.feeders because we may come up one day with a concept close to the feeder for something unrelated to transformation
I like the singular in transformation because we are talking about the system (not the multiple transformations we will create), while the plural of feeders makes it clear that you are having multiple feeder for that one system.
There was a problem hiding this comment.
And btw, while we are at it, I would avoid just FEEDER for the same reason
There was a problem hiding this comment.
Ah-ha, so DiracEntryPoint class and the project.entry-points in diracx-logic needs to match.
If we want to avoid a big transformation namespace, another approach could be to use TS_FEEDER, diracx.ts_feeders and so on.
feat(core): feeder models proposal feat(core): feeder model
9b0538b to
ba153fb
Compare
|
Thank you for the thorough review @chrisburr . I addressed your points in my second commit, and left two comments unresolved - in case follow up is needed. Thanks! |
|
|
||
| from pydantic import Field, JsonValue, model_validator | ||
|
|
||
| from .._base import BaseModel |
There was a problem hiding this comment.
in the packer proposal model this was imported as:
from pydantic import BaseModel
not sure if there is an actual difference, just noting it here since I'm going through all the PRs now.
| RESOURCES = "diracx.resources" | ||
| SERVICES = "diracx.services" | ||
| LOCK_OBJECT_TYPES = "diracx.lock_object_types" | ||
| FEEDERS = "diracx.transformation.feeders" |
There was a problem hiding this comment.
Similar comment (maybe not strictly relevant to this PR): in #1149 the PACKER was not added to the DiracEntryPoint class, should it?
|
I pushed a few unit test improvements but otherwise LGTM 👍 |
Partially fixes #1082 (part 1/5)
Superseds #1143
Waiting on the convergence of hashing in #1154
This pull request contains
diracx-core-only changes. In summary:FeederInput: minimum schema for an input dataSetFeederState: schema for a Feeder state (bookmark)NoMoreFeederInputs: model to disable a Feeder