I think today and I have a good name for package (instead of 'mistral/model')
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. This way we able to get rid of any confusing. Best Regards, Nikolay On Wed, Mar 5, 2014 at 8:50 AM, Renat Akhmerov <rakhme...@mirantis.com>wrote: > I think we forgot to point to the commit itself. Here it is: > https://review.openstack.org/#/c/77126/ > > Manas, can you please provide more details on your suggestion? > > For now let me just describe the background of Nikolay's question. > > 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: > > - Get workbook DSL (YAML) from the DB (given that it's been already > persisted earlier). > - Load it into a dictionary-like structure using standard 'yaml' > library. > - Based on this dictionary-like structure create all necessary DB > objects to track the state of workflow execution objects and individual > tasks. > - 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. > > > 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". > > 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. > > 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: > > - Is the approach itself reasonable? > - 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? > - How can we clearly distinguish between these two models so that it > wouldn't be confusing? > - Do we have a better naming in mind? > > > Thanks. > > Renat Akhmerov > @ Mirantis Inc. > > > > On 05 Mar 2014, at 08:56, Manas Kelshikar <ma...@stackstorm.com> wrote: > > Since the renaming is for types in mistral.model.*. I am thinking we > suffix with Spec e.g. > > TaskObject -> TaskSpec > ActionObject -> ActionSpec and so on. > > 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? > > > On Mon, Mar 3, 2014 at 9:43 PM, Manas Kelshikar <ma...@stackstorm.com>wrote: > >> Hi Nikolay - >> >> Is your concern that mistral.db.sqlalchemy.models.* and mistral.model.* >> will lead to confusion or something else? >> >> 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. >> >> Thanks, >> Manas >> >> >> On Mon, Mar 3, 2014 at 8:43 AM, Nikolay Makhotkin < >> nmakhot...@mirantis.com> wrote: >> >>> Hi, team! >>> >>> Please look at the commit . >>> >>> Module 'mistral/model' now is responsible for object model >>> representation which is used for accessing properties of actions, tasks etc. >>> >>> We have a name problem - looks like we should rename module >>> 'mistral/model' since we have DB models and they are absolutely different. >>> >>> >>> Thoughts? >>> >>> >>> Best Regards, >>> Nikolay >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev