I’m having a little trouble parsing your question (specifically, how the workflow ids relate to setting up the frontend to connect to multiple databases).
Currently, the workflows do not have an explicit id. Since a FW can only belong to a single Workflow, you can use any of the FireWork ids to identify a Workflow. It doesn’t have to be any specific one. Thus the FW ids and the Workflow ids are the same. This has at least some benefit, e.g. once you know a FW id you don’t need to do another query to get back the Workflow id, memorize two separate ids, or get confused between whether something was a FW id or a WF id.
So far, I have not seen any need to have an additional workflow id, so perhaps you can clarify a bit more as to why this is useful. In terms of performance, are there real issues you are hitting against? Note that if you index an array field (as we do for the Workflow nodes list), search against that array should be fast.
Btw - just a quick note - I am guessing you have noticed but I pushed major changes to the frontend in v1.1.1, so you should definitely pull those before embarking on more frontend mods.
On Wed, Sep 9, 2015 at 8:52 AM, Chris H [email protected] wrote:
I was just wondering if you could talk a little about the pros and cons of this design choice. I’m refactoring the flask views to use boostrap3, and access multiple fireworks databases in a mongo database with just one mongo connection.
Naively it seems like a workflow could have an integer key like a firework, but the way the webgui/lp.get_wf_ids() to view workflows is set up, it assigns them an id based on a node in the workflow? sometimes it’s one of the root nodes, but other times it’s the terminal node I can see in get_wf_ids it is sorted the nodes by id, but since the lowest id isn’t assigned to a root node necessarily, it could be any of them.
It seems like these “get all nodes” will be much more time expensive than just getting a workflow object with an id and unindexable, but I’m no mongo expert and thus this question
You received this message because you are subscribed to the Google Groups “fireworkflows” group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion on the web visit https://groups.google.com/d/msgid/fireworkflows/60c3c614-693d-4b4d-b50c-b8318baf7415%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.