[openstack-dev] [Mistral] DSL model vs. DB model, renaming
manas at stackstorm.com
Thu Mar 6 08:14:07 UTC 2014
I agree, let's rename data to spec and unblock the check-in.
Nikolay - Sorry for the trouble :)
On Mar 5, 2014 10:17 PM, "Renat Akhmerov" <rakhmerov at mirantis.com> wrote:
> Alright, good input Manas, appreciate.
> My comments are below...
> On 06 Mar 2014, at 10:47, Manas Kelshikar <manas at stackstorm.com> wrote:
> - 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?
> [Manas] As long as we form an abstraction between the DSL format i.e.
> YAML/XML and it consumption we will be able to move between various
> formats. (wishful) My personal preference is to not even have DSL show up
> anywhere in Mistral code apart from take it as input and transforming into
> this first level specification model - I know this is not the current state.
> Totally agree with your point. That's what we're trying to achieve.
> - How can we clearly distinguish between these two models so that it
> wouldn't be confusing?
> - Do we have a better naming in mind?
> [Manas] I think we all would agree that the best approach is to have
> precise naming.
> I see your point of de-normalizing the dsl data into respective db model
> In a previous email I suggested using *Spec. I will try to build on this -
> 1. Everything specified via the YAML input is a specification or
> definition or template. Therefore I suggest we suffix all these types with
> Spec/Definition/Template. So TaskSpec/TaskDefinition/TaskTemplate etc.. As
> per the latest change these are TaskData ... ActionData.
> After all the time I spent thinking about it I would choose Spec suffix
> since it's short and expresses the intention well enough. In conjunction
> with "workbook" package name it would look very nice (basically we get
> specification of workbook which is what we're talking about, right?)
> So if you agree then let's change to TaskSpec, ActionSpec etc. Nikolay,
> sorry for making you change this patch again and again :) But it's really
> important and going to have a long-term effect at the entire system.
> 2. As per current impl the YAML is stored as a key-value in the DB. This
> is fine since that is front-ended by objects that Nikolay has introduced.
> e.g. TaskData, ActionData etc.
> Yep, right. The only thing I would suggest is to avoid DB fields like
> "task_dsl" like we have now. The alternative could be "task_spec".
> 3. As per my thinking a model object that ends up in the DB or a model
> object that is in memory all can reside in the same module. I view
> persistence as an orthogonal concern so no real reason to distinguish the
> module names of the two set of models. If we do choose to distinguish as
> per latest change i.e. mistral/workbook that works too.
> Sorry, I believe I wasn't clear enough on this thing. I think we shouldn't
> have these two models in the same package since what I meant by "DB model"
> is actually "execution" and "task" that carry workflow runtime information
> and refer to a particular execution (we could also call it "session"). So
> my point is that these are fundamentally different types of models. The
> best analogy that comes to my mind is the relationship "class -> instance"
> where in our case "class = Specification" (TaskSpec etc.) and "instance =
> Execution/Task". Does it make any sense?
> @Nikolay - I am generally ok with the approach. I hope that this helps
> clarify my thinking and perception. Please ask more questions.
> Overall I like the approach of formalizing the 2 models. I am ok with
> current state of the review and have laid out my preferences.
> I like the current state of this patch. The only thing I would do is
> renaming "Data" to "Spec".
> Thank you.
> Renat Akhmerov
> @ Mirantis Inc.
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev