Add stored graph projections (SYN-4356) #2914
Conversation
Codecov ReportBase: 97.20% // Head: 97.10% // Decreases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## master #2914 +/- ##
==========================================
- Coverage 97.20% 97.10% -0.10%
==========================================
Files 217 218 +1
Lines 43007 43176 +169
==========================================
+ Hits 41805 41928 +123
- Misses 1202 1248 +46
Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
| @@ -198,6 +198,11 @@ def loadPkgProto(path, opticdir=None, no_docs=False, readonly=False): | |||
| with s_common.genfile(cmd_path) as fd: | |||
| cmd['storm'] = fd.read().decode() | |||
|
|
|||
| for gdef in pkgdef.get('graphs', ()): | |||
| gdef['iden'] = s_common.guid((pkgname, gdef.get('name'))) | |||
There was a problem hiding this comment.
Did you consider having this be hard-coded like the meta source iden so that a power-up could easily get() the graph it loaded?
There was a problem hiding this comment.
Yeah, I was trying to avoid allowing specifying an arbitrary iden to prevent collision issues. Generating the guid from the package+graph name seemed like a decent compromise since it would still be predictable and you could just calculate it in a module or drop it in a modconf.
There was a problem hiding this comment.
we could also do something like a 'byname' api.
There was a problem hiding this comment.
Do we persist these package graph idens anywhere other than the runtime Cortex.pkggraphs value?
There was a problem hiding this comment.
No, are there other places that they should be stored as well?
No description provided.