+1 for examples, or perhaps a link to specific code sections. >From what I did understand though, before we talk about additional changes, I'm not at all sure I'm in favor of the current ones.
First, the many-to-many relationship sounds in contrast to what Avia is currently working on with (changing Parameters relationship type) Second, so what you're saying is that now Operation models will have both "implementation" and "function", and both "inputs" and "arguments"? This seems very confusing. I'm both not convinced the original values are needed at that stage (can we have an actual use case?), but even if they are, do we really need to keep all four on the same model? How about having the original values on the OperationTemplate, and the "coerced values" (for lack of a better term..) on the Operation model? On Sun, May 21, 2017 at 11:45 AM, Arthur Berezin <[email protected]> wrote: > On Sat, May 20, 2017 at 3:47 AM Tal Liron <[email protected]> wrote: > > > Phew! Everything seems to work now: functions are parsed and evaluated > > properly. But there are some changes that require explaining. > > > > The "configuration" field in OperationTemplate and Operation models is > now > > a many-to-many with Parameter. This allows the values to fully support > > intrinsic functions and types. > > > > And I made another change in modeling: Operation now also has "function" > > and "arguments" fields, which are what actually gets used by the Task API > > instead of "implementation" and "inputs". This means that the > > "implementation" and "inputs" values are preserved as is. During the > > configuration phase the "arguments" are created according to the usual > > logic: for the execution plugin, the "configuration" is massaged into a > few > > new "arguments", and otherwise other "inputs" are also merged into > > "arguments". > > > > Why make this change? Because I really think we should not mangle the > > "inputs": they are logically different from the arguments that get sent > to > > the @operation function, even if in many cases we might treat them > > identically. Also, we cannot lose the "implementation" string: plugins > will > > need to know what users put in there. The change is not big in terms of > > extra code, but I think it helps make the code easier to understand: you > > can see exactly what is being merged into the final "arguments" for the > > task. The configure phase is now constructive rather than destructive: > > existing fields are not changed. > > > > > Tal, could you provide several example models to showcase these changes? > > > > > > > Before moving forward with a PR I want to see what other committers think > > about also renaming "implementation" and "inputs" in the Task API to > > "function" and "arguments". For now I'm leaving them as is, but I think > it > > would be even cleaner if they followed the new naming convention in > > modeling. I continue being unhappy about how the Task API treats both > > arguments and inputs as the same thing and squashing them all together... > > :( However, for now I would be happy if we just called them "arguments", > > because that's what they really are for us. > > > > -- > > Tal Liron > > Solution Architect > > [email protected] | +13123758299 <(312)%20375-8299> > > Cloudify | http://getcloudify.org > > < > > http://getcloudify.org?utm_source=signaturesatori&utm_ > medium=email&utm_campaign=general_signature > > > > > > > <https://twitter.com/CloudifySource> > > <https://www.linkedin.com/groups/8467478> > > <https://github.com/cloudify-cosmo> <https://github.com/cloudify-cosmo > > > > [image: Azure Webinar] > > < > > http://getcloudify.org/webinars/Azure-plugin-for- > cloudify-webinar.html?utm_source=signaturesatori&utm_ > medium=email&utm_campaign=general_signature > > > > > >
