Re: [tosca] key_schema in TOSCA 1.3?

Thanks everybody for the discussion and quick decision!

As an addendum, I'll just point out there is a workaround for cases where you need to send a map with arbitrary keys to an external system. Just use a list of entries:

data_types:

Â MyEntry:

ÂÂÂ Key: MyKeyType

ÂÂÂ Value: MyValueType

node_types:

Â MyNode:

ÂÂÂ properties:

ÂÂÂÂÂ my_fake_map:

ÂÂÂÂÂÂÂ type: list

ÂÂÂÂÂÂÂ entry_schema: MyEntry

The one caveat is that TOSCA would not be able to verify the uniqueness of keys, but at least there is a functional solution.

Is it worth pointing this out in the spec to preempt questions about the key_schema limitation?

On Mon, Sep 16, 2019 at 4:15 PM Chris Lauwers <lauwers@ubicity.com> wrote:

As a compromise, perhaps we can restrict key_schema to only allow scalar types (or types that derive from scalar types).

Â

Chris

Â

From: Tal Liron [mailto:tliron@redhat.com]
Sent: Monday, September 16, 2019 10:09 AM
To: Calin Curescu <calin.curescu@ericsson.com>
Cc: Chris Lauwers <lauwers@ubicity.com>; tosca@lists.oasis-open.org
Subject: Re: [tosca] key_schema in TOSCA 1.3?

Â

I would like to ask the group to reconsider the new "key_schema" feature.

Â

While it's true that complex keys are supported in YAML, hashtables with complex keys are not widely supported across programming languages, data formats (JSON), databases (relational, graph), memory caches, etc.

Â

In working to implement this feature in Puccini I am hitting many problems that would require adding workarounds with considerable complexity, in particular in its interfaces with the orchestration systems it supports.

Â

My guess is that it was added to provide some grammatical completeness, but I would like to re-discuss its practicality and necessity. Can we add this to the meeting agenda?

Â

tosca message