<div dir="ltr">I think today and I have a good name for package (instead of 'mistral/model')<br><br>How do you think about to name it 'mistral/workbook'? I.e., It means that it contains modules for work with workbook representation - tasks, services, actions and workflow.<br>
<br>This way we able to get rid of any confusing.<br><div><br></div><div><br></div><div class="gmail_extra">Best Regards,<br>Nikolay<br><br><div class="gmail_quote">On Wed, Mar 5, 2014 at 8:50 AM, Renat Akhmerov <span dir="ltr"><<a href="mailto:rakhmerov@mirantis.com" target="_blank">rakhmerov@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">I think we forgot to point to the commit itself. Here it is: <a href="https://review.openstack.org/#/c/77126/" target="_blank">https://review.openstack.org/#/c/77126/</a><div>
<br></div><div>Manas, can you please provide more details on your suggestion?</div><div><br></div><div>For now let me just describe the background of Nikolay’s question.</div><div><br></div><div>Basically, we are talking about how we are working with data inside Mistral. So far, for example, if a user sent a request to Mistral “start workflow” then Mistral would do the following:</div>
<div><ul><li>Get workbook DSL (YAML) from the DB (given that it’s been already persisted earlier).</li><li>Load it into a dictionary-like structure using standard ‘yaml’ library.</li><li>Based on this dictionary-like structure create all necessary DB objects to track the state of workflow execution objects and individual tasks.</li>
<li>Perform all the necessary logic in engine and so on. The important thing here is that DB objects contain corresponding DSL snippets as they are described in DSL (e.g. tasks have property “task_dsl”) to reduce the complexity of relational model that we have in DB. Otherwise it would be really complicated and most of the queries would contain lots of joins. The example of non-trivial relation in DSL is “task”->”action name”->”service”->”service actions”->”action”, as you can see it would be hard to navigate to action in the DB from a task if our relational model matches to what we have in DSL. this approach leads to the problem of addressing any dsl properties using hardcoded strings which are spread across the code and that brings lots of pain when doing refactoring, when trying to understand the structure of the model we describe in DSL, it doesn’t allow to do validation easily and so on.</li>
</ul><div><br></div></div><div>So what we have in DB we’ve called “model” so far and we’ve called just “dsl” the dictionary structure coming from DSL. So if we got a part of the structure related to a task we would call it “dsl_task”.</div>
<div><br></div><div>So what Nikolay is doing now is he’s reworking the approach how we work with DSL. Now we assume that after we parsed a workbook DSL we get some “model”. So that we don’t use “dsl” in the code anywhere this “model” describes basically the structure of what we have in DSL and that would allow to address the problems I mentioned above (hardcoded strings are replaced with access methods, we clearly see the structure of what we’re working with, we can easily validate it and so on). So when we need to access some DSL properties we would need to get workbook DSL from DB, build this model out of it and continue to work with it.</div>
<div><br></div><div>Long story short, this model parsed from DSL is not the model we store in DB but they’re both called “model” which may be confusing. For me this non-DB model more looks like “domain model” or something like this. So the question I would ask ourselves here:</div>
<div><ul><li>Is the approach itself reasonable?</li><li>Do we have better ideas on how to work with DSL? A good mental exercise here would be to imagine that we have more than one DSL, not only YAML but say XML. How would it change the picture?</li>
<li>How can we clearly distinguish between these two models so that it wouldn’t be confusing?</li><li>Do we have a better naming in mind?</li></ul><div><br></div></div><div>Thanks.</div><div><span class="HOEnZb"><font color="#888888"><br>
<div>
<div>Renat Akhmerov</div><div>@ Mirantis Inc.</div><div><br></div><br>
</div></font></span><div><div class="h5">
<br><div><div>On 05 Mar 2014, at 08:56, Manas Kelshikar <<a href="mailto:manas@stackstorm.com" target="_blank">manas@stackstorm.com</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr">Since the renaming is for types in mistral.model.*. I am thinking we suffix with Spec e.g. <div>
<br></div><div>TaskObject -> TaskSpec</div><div>ActionObject -> ActionSpec and so on.</div><div><br></div>
<div>The "Spec" suggest that it is a specification of the final object that ends up in the DB and not the actual object. Multiple actual objects can be derived from these Spec objects which fits well with the current paradigm. Thoughts?</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 3, 2014 at 9:43 PM, Manas Kelshikar <span dir="ltr"><<a href="mailto:manas@stackstorm.com" target="_blank">manas@stackstorm.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Nikolay - <div><br></div><div>Is your concern that mistral.db.sqlalchemy.models.* and mistral.model.* will lead to confusion or something else? </div>
<div><br></div><div>IMHO as per your change model seems like the appropriate usage while what is stored in the DB is also a model. If we pick appropriate names to distinguish between nature of the objects we should be able to avoid any confusion and whether or not model appears in the module name should not matter much.</div>
<div><br></div><div>Thanks,</div><div>Manas</div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div>On Mon, Mar 3, 2014 at 8:43 AM, Nikolay Makhotkin <span dir="ltr"><<a href="mailto:nmakhotkin@mirantis.com" target="_blank">nmakhotkin@mirantis.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">Hi, team! <br><br>Please look at the commit .<br><div><br></div><div>Module 'mistral/model' now is responsible for object model representation which is used for accessing properties of actions, tasks etc.<br clear="all">
<div><br></div><div>We have a name problem - looks like we should rename module 'mistral/model' since we have DB models and they are absolutely different.<br></div><div><br></div><div><br></div><div>Thoughts?</div>
<div><br></div> <br><div dir="ltr"><div><font>Best Regards,</font></div><div><font>Nikolay</font></div></div>
</div></div>
<br></div></div><div>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></div></blockquote></div><br></div>
</blockquote></div><br></div>
_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div></div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br>
</div></div>