2.9 KiB
2.9 KiB
TODOs
v0.3.1
- document the supported element units
- document the expected call pattern
- full workflow with main process id x2
- lazy load with subprocess id x2
- restore main process id/something related to call activity
- in the integration tests, do some save/restore (maybe on human task?)
- or after each task and requery for that element id? perf?
mostly unordered queue
- write log under each cache key
- new api to get element units without using the cache
- new api to write existing element units to the cache
- split cache into spiff-element-units-disk-cache
- split spiffworkflow-specs to own lib
- add support for the
all_specs
structure - cleanup the auto generated descriptions (pypi page is blank)
- are there too many to_strings?
- yes tied into domain objects vs serde objects
- there is some issue in the tests when after an rmtree the cache dir can't be created again
- create a test for it?
- not sure if it affects callers that own the cache dir
- ^ wtf was i thinking about here?
- there is some issue where it takes two integration test runs for multiple-call-activities to catch up
- no its on run of the integration tests hashes for the ResumableSubprocess and index order change
- stable order in the manifest problem?
- can dmn
decision_table
s be lazy loaded forBusinessRuleTasks
?- for "free" if we make a subprocess out of them and swap the node for a
CallActivity
? - or (in some situations?) "compiled"?
- for "free" if we make a subprocess out of them and swap the node for a
- using the serde objects as domain objects is too expensive/restrictive
- have intermediate objects that are ref/slice based?
- most likely just do for element units before returning them out
- could help with spec mixin interactions?
- specific task types?
- need to have test versions of element units
- build.rs? read from disk? just hardcode?
- how much do we leverage the integration tests vs rust tests?
- when we don't use the serde objects, unit tests become easier?
- port/use/something the env macros from typeahead
- more macro leverage?
- push to crates.io
good first issues
- when pushing for keys, if the last index is what is about to be pushed, can skip duplicating the index
- see simple call activity main manifest
- "mutliple-call-activities/multiple_call_activities.json" naming has tripped me up 2x now
- look at more (self) -> X to transition objects instead of clone
- must reduce the number of clones or somehow else be cleaner
- manifest from_element_units?
- move more things to Iterator (element_ids, processes, etc)
- maybe not run full build matrix on pr?
- nothing real arch/os specific happening so just linux/x86_64 and sdist?
- fill out the rest of the specs.rs is_empty function
- run integration tests as part of CI
- run cargo tests as part of CI
- https://github.com/actions-rs/cargo
- also maybe just build the dev image and use make to also get integration tests?